Percona Server for MongoDB 8.3 Technical Preview Is Now Available

Percona Server for MongoDB 8.3 is available today as a Technical Preview. It is not for production. It is for your lab, your staging cluster, and your benchmark harness – and for sharing with us what works and what does not. Especially if this version is your segue to leverage upcoming full-text and vector search capabilities. Many users have been asking when Percona would ship 8.2 or 8.3 – this is the answer. We are jumping straight to 8.3. In this blog post, I share everything you have to know before upgrading to 8.3. I gathered all available information, so you don’t need to.  

Why this release matters

MongoDB 8.3 Community went GA in May 2026. This was the fourth significant MongoDB release in nearly 2 years. I have observed that the upstream MongoDB Community project is now moving faster than most organizations’ upgrades (adoption telemetry data later in this blog post). Nonetheless, Percona’s job is to ensure that the free, enterprise-grade path does not fall behind, and you still can get the performance of the current release without giving up data-at-rest encryption with KMIP, HashiCorp Vault, or OpenBao, audit logging, external LDAP authentication, OpenID Connect, File copy-based initial sync, in-memory engine, or audit log with log redaction. All of that stays in Percona Server for MongoDB 8.3, and it stays free and open. This is the Percona way.

I’ll not discover America by writing that the data layer now has to move at AI speed. Application teams are shipping agentic workloads today, and that’s why performance and functional requirements are growing exponentially. Two years ago, we experienced occasional query retries and recall storms, critical security patches, and multi-region deployments could trade compliance for latency. Now, this is bread-and-butter we need to deal with every day. 

I’m happy to share that Percona has published Percona Server for MongoDB 8.3 in Technical Preview today. 8.3 is not one release forward from 8.0 – it is three. Everything that landed in the two minor releases (and 8.1 Rapid Release) in between arrives at once. Percona Server for MongoDB 8.3 is the most performant release so far! And besides the performance boost and many functional improvements, I’ve described below, I’m personally most excited about the fact that this release enables full-text search and vector search capabilities, so you can finally equip your applications with AI power using the same MongoDB. More about that in my next blog post – brace yourself!

What’s new compared to 8.0

Because we’re skipping 8.1 and 8.2 releases, the delta is large. I grouped the highlights by what you’d actually notice.

Performance

Percona Server for MongoDB inherits performance optimization from the upstream MongoDB Community:

• Up to 195% higher throughput on time-series bulk insertions
• Up to 40% on match filter queries
• Up to 20% on queries against documents with arrays
• Up to 10% on in-cache read workloads
• Up to 5% reduction in CPU utilization

Moreover, Percona Server for MongoDB 8.3 now offers faster initial sync, faster time-series bulk inserts, and reduced multi-planning costs for queries. As always, your mileage depends entirely on the shape of your workload.

Query planning

The Cost-Based Ranker (CBR) is now the default plan selection mechanism for eligible queries. Multi-planning gets a short trial period; if it can’t settle on a plan, CBR evaluates each plan node by estimated cost. New serverStatus counters under metrics.query.cbr and new explain output let you see when CBR was used and how often it won. 

Query language and aggregation

• Native hybrid search (full-text search and vector search) is enabled with Percona Search for MongoDB (fork of mongodb/mongot project) via $scoreFusion and $rankFusion
• Array element indexes are now accessible in $map, $filter, and $reduce via the new arrayIndexAs field and the $$IDX system variable
• New expressions: $subtype, $createObjectId, $hash, $hexHash, $serializeEJSON, $deserializeEJSON, $currentDate
• $convert gains a base argument (base 2/8/10/16) and can convert strings representing arrays and objects, plus BinData ↔ numeric arrays in both directions
• $mergeObjects now works inside $setWindowFields
• $concatArrays and $setUnion accumulators, the $listClusterCatalog stage, and $lookup across multiple encrypted collections for CSFLE and Queryable Encryption

Storage and operations

The most operationally useful change for anyone running in containers is the WiredTiger cache size, which can now be set as a percentage of available memory via –wiredTigerCacheSizePct / storage.wiredTiger.engineConfig.cacheSizePct, instead of a fixed GB value. If you run Percona Server for MongoDB on Kubernetes via our Percona Operator for MongoDB. This alone is worth the upgrade!

Also worth knowing:

• zstd negative compression levels – the supported range widens to -7 through 22, trading ratio for speed
• Initial-sync index builds now use 10% of available RAM by default, tunable, and bounded
• terminateSecondaryReadsOnOrphanCleanup (on by default) terminates long-running secondary reads that started before a chunk migration was committed. Previously, those reads continued and could silently return incomplete results with no error. orphanCleanupDelaySecs moves from 900 to 3600 to accommodate this.

Sharding

• removeShard is deprecated, replaced by four commands that give you granular control over draining and removal: startShardDraining, stopShardDraining, shardDrainingStatus, commitShardRemoval. A parallel set exists for the embedded-to-dedicated config server transition.
• Sharded clusters: DDL operations and applyOps can now run only on mongos across all sharded clusters.
• New mongod –replicaSetConfigShardMaintenanceMode converts a replica set primary directly into an embedded config shard, skipping the dedicated config server replica set step.
• Shard-level query stats now include queries that originated on mongos. Previously, most forwarded queries were invisible in shard-level stats.

Security

• Software Bills of Materials (SBOMs) are attached to our deliverables across all release distribution channels. SBOMs improve software supply chain transparency by documenting the components and dependencies included in a build. They are generated automatically as part of the release pipeline in the industry-standard CycloneDX format.
• New pre-auth connection resource limits (capMemoryConsumptionForPreAuthBuffers, preAuthMaximumMessageSizeBytes, messageSizeErrorRateSec)
• Ingress connection establishment rate limiting and per-application exemptions from ingress request rate limiting. See ingressRequestRateLimiterApplicationExemptions. for more.

Observability

• Query memory tracking: inUseTrackedMemBytes and peakTrackedMemBytes in $currentOp, profiler output, slow query logs, explain results, and $planCacheStats
• Slow in-progress query logs: a lightweight entry emitted once per query when it exceeds slowOpInProgressThreshold, so you can see a slow query while it is still running rather than after it finishes
• FTDC now collects connPoolStats for mongod
• Standardized disk-spill metrics (spills, spilledBytes, spilledRecords, spilledDataStorageSize) in explain output
• New TTL, replication lag, and admission control metrics in serverStatus

What’s changed: Read this before you upgrade

Upgrade path. To go from 8.0 directly to 8.3, your 8.0 deployment must have featureCompatibilityVersion set to 8.0. Verify with db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 }). All cluster members must be running before you start.

Geospatial indexes may need rebuilding. Index generation now prioritizes GeoJSON over legacy numeric coordinates when a document contains both. If your documents have legacy numeric coordinates preceding GeoJSON coordinates and your existing indexes depend on the old ordering, rebuild them and re-verify your geospatial query results. Separately, 2dsphereIndexVersion now defaults to 4.

Error codes changed. Exceeding the $facet 100 MB limit now returns ExceededMemoryLimit (146) instead of 4031700. Upserts producing an oversized BSON object return 10334 BSONObjectTooLarge instead of 17419/17420. Anything in your stack that string-matches error codes needs updating.

$text sorted-by-score queries can now fail. The TextOr stage is capped at 100 MB. With allowDiskUse: true, it spills; with false the query errors out. Previously, it was unbounded, which is to say, previously, it could OOM your node instead.

Pre-epoch date arithmetic shifts by one second. $dateAdd and $dateSubtract, with a non-millisecond unit, on dates before 1970-01-01 now return a result that is one second greater. This propagates into $setWindowFields and $densify.

Monitoring integrations will need attention. The service field is removed from serverStatus output, and cpuNanos is moved from operationMetrics into $queryStats (Linux only).

Other behavior changes: $$CLUSTER_TIME now throws an error in standalone deployments. db.collection.validate({full: true}) no longer implicitly enables checkBSONConformance. explain() against a non-existent database on a sharded cluster no longer creates the database. Time series collections reject a timeField starting with $ and reject an index named or hinted “_id_”.

One-way doors from sharding to the replica set. A replica set that was previously a sharded cluster cannot be converted back into a sharded cluster – residual sharding metadata blocks it. And downgrading from 8.3 requires you to first drop 2dsphere version 4 indexes and update or drop any views, validators, or collection validation rules that use 8.3-only expressions.

Don’t stay behind: What the telemetry says about version adoption

We analyzed anonymous product telemetry from Percona Server for MongoDB over the last 12 months to assess the share of active database instances. Major version adoption takes more than a year for many users and organizations. PSMDB 8.0 went from roughly a fifth of the installed base to nearly half over twelve months. That is healthy, and it is also slower than a release cadence of four significant upstream versions in 19 months. The gap between how quickly MongoDB ships and how quickly the installed base moves is why we are publishing a Technical Preview instead of delaying until a GA build. Also, that’s a strong signal to move to version 8.0 if you haven’t already, and then explore 8.3. 

Moreover, if you run (or consider running) your Percona Server for MongoDB in a container deployment – Containerized deployments now account for about 24% of active instances, up from roughly 21% a year ago – so still Docker and Kubernetes for MongoDB are the thing, and this release improvement of percentage-based WiredTiger cache sizing is probably the most immediately useful thing.

Technical Preview: What does that actually mean

A Technical Preview build is complete enough to install, benchmark, and evaluate. It meets equal quality and packaging requirements as any other 8.0 patch. However, it has not undergone the full release qualification we require for a GA release with respect to ecosystem compatibility:

• Percona Backup for MongoDB (PBM): logical backup and restore against an 8.3 server may cause some issues. Do not rely on it to protect anything you care about. Current known limitations are around logical backup and restore, and PITR. If you’re interested in details and progress on those, follow our Jira tickets.
• Percona ClusterSync for MongoDB (PCSM): replication to or from an 8.3 cluster is unvalidated.
• Percona Monitoring and Management (PMM): metric collection may be incomplete or fail outright, particularly given the serverStatus and cpuNanos changes described above.

To be clear about what this is and isn’t: upstream MongoDB Community 8.3 is a stable, production-suitable release with support through October 2029. The Technical Preview label applies to Percona’s build, not to MongoDB 8.3 itself. It reflects where we are in qualifying our surrounding tooling against this version, and not a judgment about upstream stability.

So if you need a fully-integrated Percona Server for MongoDB today, 8.0 is still the answer. The current release is 8.0.26-11. When our 8.3 build reaches GA, that changes.

How to start

We recommend installing (or upgrading) Percona Server for MongoDB using the official Percona repositories via the percona-release repository management tool and your system’s package manager. For further instructions, start with the quickstart guide for the fresh installation or an upgrade procedure from 8.0.

Feedback needed

This is the part that matters. A Technical Preview is only worth shipping if it yields findings.

We are specifically interested in:

• Percona-specific feature behavior: data-at-rest encryption with KMIP or Vault, audit logging, external LDAP authentication, OpenID Connect, file copy-based initial sync, hot backup, and audit logging with log redaction.
• PBM, PCSM, and PMM interactions. We know these might be limited. Knowing how they fail helps us prioritize and fix them within the next release cycle.
• Upgrade friction from 8.0, especially on sharded clusters and around the geospatial index and removeShard changes.

Post your findings in the Percona Server for MongoDB forum. Include your topology, your workload shape, and the exact version you tested. Engineering reads that category directly, and feedback from this preview will shape what the GA build looks like.

If you find a security issue, please report it through Percona Security disclosure process rather than posting publicly.

Percona Server for MongoDB is a free, source-available, drop-in replacement for MongoDB Community Edition with enterprise-grade features. Telemetry figures in this post are derived from anonymous product telemetry.