Executive Summary
Enterprise Database Platforms manage data for applications, with choices driven by matching the data model and scale to the workload. Key considerations include managed cloud services versus self-management, and weighing open engines like PostgreSQL against proprietary options such as Oracle, SQL Server, MongoDB, CockroachDB, and Spanner.
Most applications don’t need an exotic database — they need the boring one that fits the data model and that your team can operate, which is why PostgreSQL has become so many architectures’ default answer.
Oracle, PostgreSQL, SQL Server, MongoDB, and distributed engines like CockroachDB and Spanner cover the spectrum from traditional relational OLTP to document stores and globally distributed SQL. The real decisions are matching the data model and scale to the workload, choosing managed cloud services over self-management, and weighing the open, extensible pull of PostgreSQL against legacy licensing and the lock-in of proprietary cloud engines.
This guide provides a vendor-neutral evaluation framework for 10 leading platforms, weighing data model and workload fit, managed-versus-self-managed operations, and the trade-off between open engines and proprietary cloud lock-in so you can match a database to the job rather than default to habit or over-engineer for scale you don’t have.
Why Enterprise Database Platforms Matter for Enterprise Strategy
Enterprise database platforms matter because they are a sticky decision impacting workload data models, operational burden, and licensing costs over a long lifespan. Selection should align with workload needs—relational for transactional integrity, document for flexible schemas, or distributed SQL for global scale—often favoring open engines like PostgreSQL. Consider managed cloud services versus self-hosting, and the impact of source-available terms and recent license changes.
Database selection should follow the workload: relational for transactional integrity, document for flexible schemas, distributed SQL for genuine global scale — and most applications are well served by a capable open engine like PostgreSQL rather than something exotic. Weigh operational burden and licensing heavily, because the cost of running and being locked into a database compounds quietly over its long life.
PostgreSQL’s extensible ecosystem, managed and serverless cloud databases, and AI-driven operations are reshaping the category, even as proprietary distributed engines push global scale. Weigh portability and operational simplicity against raw capability, because a database is among the stickiest decisions in your stack and migrating off one later is rarely cheap.
Should you build or buy Enterprise Database Platforms?
For most new OLTP systems, buy a managed cloud service like PostgreSQL (RDS/Aurora/Cloud SQL/Azure DB) to offload operational toil and maintain portability. Deviate only when specific needs, such as document-shaped data (MongoDB Atlas/Couchbase), globally distributed writes (Spanner/CockroachDB), or existing Microsoft/Oracle estates, necessitate a different engine. Always confirm license terms like SSPL or BSL before standardizing.
Nobody writes a storage engine from scratch anymore, so this is not a literal build-vs-buy. The real decisions are three: which data model and consistency model the workload genuinely needs (relational, document, key-value, or distributed SQL); whether you self-manage the engine or consume a managed cloud service and inherit its lock-in and patch cadence; and whether the engine’s license is acceptable for how you intend to deploy it. The right default for most new OLTP systems is managed PostgreSQL — deviate from it only when a specific requirement forces the issue.
| Your Situation | Recommended Path | Rationale |
|---|---|---|
| New transactional app, conventional relational data, no extreme scale | Managed PostgreSQL (RDS / Aurora / Cloud SQL / Azure DB) | Postgres is the gravitational default: open license, deep extension ecosystem (PostGIS, pgvector), and a managed flavor on every cloud. You keep portability and avoid a license negotiation while offloading patching and backups. |
| Flexible / evolving schema, document-shaped data, developer velocity prized | Document store (MongoDB Atlas / Couchbase) — or Postgres JSONB | A native document model fits nested, fast-changing data and hierarchical reads. But first ask whether Postgres’ JSONB covers it — running one engine beats two. Choose a dedicated document DB when the access patterns are truly document-first, not relational-with-a-blob. |
| Globally distributed writes with strong consistency and horizontal scale | Distributed SQL (Spanner / CockroachDB / Aurora DSQL) | When a single primary genuinely can’t hold the write volume or the data must be consistent across regions, distributed SQL earns its complexity. Confirm the need is real — most apps scale far on one large managed Postgres with read replicas before they need this. |
| Heavy Microsoft / Oracle estate with apps and skills built around it | Stay on SQL Server / Azure SQL or Oracle — modernize in place | Rip-and-replace of a mission-critical proprietary engine is rarely worth the migration risk on its own. Lean on Azure SQL Hyperscale or Oracle Autonomous to cut operational toil, and reserve Postgres migration for systems where the licensing math or strategy clearly justifies it. |
| Caching, sessions, leaderboards, queues — microsecond key-value access | In-memory store (Redis / Valkey) or DynamoDB, beside your system of record | These are a complement, not a system of record. Note the license fork: Redis is OSI-licensed again under AGPL from Redis 8, while the Linux-Foundation Valkey fork stays BSD — pick deliberately, as both are now drop-in for most caching uses. |
| License terms block your deployment (you ship/host software, or avoid source-available) | Choose an OSI-licensed engine or a managed service that absorbs the license | SSPL (MongoDB), enterprise/BSL terms (CockroachDB), and the Redis/Elastic reversals make the license a real gate. PostgreSQL’s permissive license — or consuming the engine as a managed cloud service — sidesteps most of these constraints. |
How do you evaluate Enterprise Database Platforms?
To evaluate enterprise database platforms, weigh criteria like data model and query fit (25%), consistency, scale, and HA (20%), and operability and managed-service experience (20%) against your workload. Also consider licensing and portability (15%), security and compliance (12%), and ecosystem and talent (8%). Focus on production realism, failover, and upgrade paths, not just raw benchmarks.
Weight these domains against your actual workload, not a generic feature grid. For operational databases, data-model fit and the realism of running the thing in production tend to decide success far more than raw benchmark numbers — and the license and operating model are scored here as first-class criteria, not afterthoughts. Adjust the weights for your case: a fintech with global writes will lift scale and consistency; a lean team will lift operability and the managed-service experience.
| Capability Domain | Weight | What to Evaluate |
|---|---|---|
| Data Model & Query Fit | 25% | Match of the engine to the workload: relational integrity and joins, document/JSON flexibility, key-value latency; transaction isolation levels and ACID guarantees; SQL standard coverage and dialect quirks; secondary indexes, full-text and vector (pgvector / Atlas Search) support; foreign keys and referential integrity where you need them |
| Consistency, Scale & HA | 20% | Single-primary vs. multi-writer; synchronous vs. async replication and resulting RPO; read-replica and sharding story; horizontal write scale and global/multi-region behavior (strong vs. eventual consistency); failover time, achievable RTO, and how partitions are handled under load |
| Operability & Managed-Service Experience | 20% | Quality of the managed offering (RDS/Aurora, Azure SQL, Cloud SQL/AlloyDB) vs. self-managed burden; in-place and major-version upgrade path; backup/PITR, observability, and connection pooling; autoscaling and serverless options; day-2 toil — vacuum/compaction, index bloat, rebalancing — and the depth of the DBA skills it demands |
| Licensing & Portability | 15% | License class and its real constraints: OSI open source (PostgreSQL, MySQL, Valkey, Redis 8 AGPL) vs. source-available (MongoDB SSPL, CockroachDB enterprise/BSL) vs. proprietary (Oracle, SQL Server); cloud lock-in of proprietary engines (Aurora, Spanner, DynamoDB); wire-protocol and SQL-dialect compatibility that preserves an exit; audit exposure on proprietary metrics |
| Security & Compliance | 12% | Encryption at rest and in transit, TLS enforcement, and key management (BYOK/HSM); row- and column-level security and fine-grained RBAC; field-level / queryable encryption for sensitive data; audit logging; data-residency controls and certifications (SOC 2, ISO 27001, HIPAA, PCI, FedRAMP) on the managed service |
| Ecosystem & Talent | 8% | Driver and ORM maturity across your languages; migration and CDC tooling (logical replication, Debezium, DMS); breadth of extensions and integrations; size and hireability of the talent pool; quality of docs and the support path — first-party vendor vs. third-party (EDB, Percona, Crunchy) for open engines |
Which vendors lead in Enterprise Database Platforms?
Consider vendors across four camps: proprietary relational (Oracle, Microsoft SQL Server), open-source relational (PostgreSQL, MySQL), NoSQL/document and key-value (MongoDB, Couchbase, Redis/Valkey, DynamoDB), and distributed SQL (Spanner, CockroachDB, AlloyDB, Aurora DSQL). Cloud providers (AWS, Azure, Google) are the dominant delivery channel. PostgreSQL is a leader due to its permissive license and ecosystem, while Oracle Database and Microsoft SQL Server lead proprietary options.
| Vendor | Positioning | Best for |
|---|---|---|
| PostgreSQL (+ managed: RDS, Cloud SQL, Azure DB) | Leader — Open-Source Default | Almost any new transactional application — the default you should have to argue your way out of |
| Oracle Database | Leader — Proprietary | Large enterprises with mission-critical, Oracle-architected workloads and the licensing discipline to run them |
| Microsoft SQL Server / Azure SQL | Leader — Proprietary | Microsoft-aligned enterprises wanting a refined relational engine with a strong Azure managed path |
| MySQL (+ Aurora MySQL, HeatWave) | Strong — Open-Source | Read-heavy web workloads and teams with deep existing MySQL investment and skills |
| MongoDB (Atlas) | Strong — Document NoSQL | Application teams with document-shaped, evolving data who want a managed, multi-cloud document platform |
| Amazon Aurora & DynamoDB | Strong — AWS Data Layer | AWS-committed organizations wanting managed relational (Aurora) and internet-scale key-value (DynamoDB) without running servers |
| Google AlloyDB & Cloud Spanner | Strong — GCP Data Layer | GCP-aligned teams wanting high-performance managed Postgres (AlloyDB) or genuinely global, strongly consistent relational scale (Spanner) |
| CockroachDB | Strong — Distributed SQL | Teams needing resilient, geo-distributed SQL across regions or clouds without proprietary cloud lock-in |
| Couchbase (Capella) | Strong — Multi-Model NoSQL | Enterprises needing document plus memory-first key-value performance, or mobile/edge data sync, in one platform |
| Redis / Valkey | Strong — In-Memory | Caching and latency-critical key-value workloads alongside a primary database — choosing Redis or Valkey by license preference |
The operational-database market sorts into four overlapping camps. Proprietary relational incumbents — Oracle and Microsoft SQL Server — still run the most mission-critical estates and monetize through licensing and now managed cloud editions. Open-source relational — PostgreSQL and MySQL — has become the default for new builds, consumed mostly as a managed cloud service. NoSQL / document and key-value — MongoDB, Couchbase, Redis/Valkey, DynamoDB — targets flexible-schema and latency-sensitive workloads. And distributed SQL (NewSQL) — Spanner, CockroachDB, AlloyDB, Aurora DSQL — chases horizontal write scale with relational semantics. Most shortlists now compare across these camps, and the cloud providers (AWS, Azure, Google) sit underneath all of them as the dominant delivery channel.
The defining 2024–2025 dynamic is licensing. A wave of vendors moved away from permissive open source to source-available terms to defend against cloud-provider monetization — and several partially reversed. That history now shapes selection as much as features do, and it is the reason PostgreSQL, whose permissive license has never wavered, keeps pulling migrations toward it.
PostgreSQL (+ managed: RDS, Cloud SQL, Azure DB)
Leader — Open-Source DefaultStrengths: The category’s center of gravity and the most-used database among professional developers in the 2025 Stack Overflow survey. Permissive PostgreSQL license with no source-available drama, an unmatched extension ecosystem (PostGIS for geospatial, pgvector for AI embeddings, TimescaleDB for time-series), strong SQL standard coverage, and a first-party managed flavor on every cloud. Migrations from other engines overwhelmingly head toward it. Considerations: Vanilla Postgres scales writes on a single primary — horizontal write scale means sharding (Citus) or moving to a distributed-SQL engine. Self-managed Postgres demands real expertise (vacuum, bloat, connection limits, major-version upgrades); first-party enterprise support comes from third parties (EDB, Crunchy, Percona). Managed-service feature sets and version cadence vary by cloud.
Oracle Database
Leader — ProprietaryStrengths: The deepest, most battle-tested relational engine for the largest and most demanding OLTP estates, with RAC for high availability, partitioning, advanced security, and Exadata for extreme performance. Autonomous Database automates tuning and patching; Database 23ai folds in vector search and built-in AI. Unmatched for workloads already architected around its features. Considerations: The most expensive and most license-audited platform in the category: per-processor / Named-User-Plus metrics, costly options (RAC, partitioning, multitenant), and notoriously aggressive compliance reviews — especially around virtualization and cloud cores. Strong gravitational lock-in. Rarely the right choice for a greenfield app that doesn’t already need it.
Microsoft SQL Server / Azure SQL
Leader — ProprietaryStrengths: A polished, full-featured relational engine with excellent tooling (SSMS), strong in-memory and columnstore options, and tight integration across the Microsoft stack and Power BI. Azure SQL Database (especially the Hyperscale tier) delivers a strong managed PaaS, and Azure Hybrid Benefit lets existing core licenses with Software Assurance carry into the cloud. The natural choice for .NET and Microsoft-centric shops. Considerations: Per-core licensing (Standard vs. Enterprise) gets expensive at scale, and edition feature-gating pushes you toward Enterprise. Best-in-class experience is Windows/Azure-centric despite Linux support; portability off T-SQL and SQL Server-specific features is limited. Azure SQL is a managed service, so you trade some control for the convenience.
MySQL (+ Aurora MySQL, HeatWave)
Strong — Open-SourceStrengths: The web’s long-time default and still ubiquitous for read-heavy applications, with a vast talent pool and operational familiarity. Open-source (GPL) and available managed everywhere; Oracle’s HeatWave adds an in-database analytics and ML accelerator that closes the OLTP/OLAP gap, and Aurora MySQL is a popular cloud-optimized variant. Forks like MariaDB and Percona keep the ecosystem competitive. Considerations: Stewardship sits with Oracle, which makes some communities wary and is part of why new projects increasingly start on Postgres instead. Historically thinner on advanced SQL, extensibility, and complex-query and concurrency handling than Postgres. The most differentiated capabilities (HeatWave) are tied to Oracle’s cloud.
MongoDB (Atlas)
Strong — Document NoSQLStrengths: The leading document database and a developer favorite for flexible, nested, fast-evolving schemas. Atlas is a mature managed service deployable across AWS, Azure, and GCP (including multi-cloud clusters), with built-in full-text (Atlas Search), vector search, and Queryable Encryption that lets you query while data stays encrypted. Excellent developer experience and horizontal scaling via sharding. Considerations: The self-managed Community edition is licensed under SSPL, which the OSI does not recognize as open source and which blocks offering Mongo as a competing service — a genuine constraint for some buyers. A poor fit for heavily relational, multi-table-transaction data; modeling and the aggregation pipeline carry a NoSQL learning curve. Atlas spend grows with cluster tier and data volume.
Amazon Aurora & DynamoDB
Strong — AWS Data LayerStrengths: AWS’s flagship operational pairing. Aurora is a cloud-rearchitected MySQL/PostgreSQL with a distributed storage layer, fast replicas, Serverless v2 autoscaling, and now Aurora DSQL for serverless distributed SQL with multi-region active-active. DynamoDB is a fully managed key-value/document store delivering consistent single-digit-millisecond latency at any scale with zero-idle serverless billing and active-active Global Tables. Both integrate deeply with the rest of AWS. Considerations: Both are AWS-only — the strongest lock-in on this list, with egress costs penalizing multi-cloud exits. Aurora is wire-compatible with Postgres/MySQL (easing some portability) but its best features are proprietary; DynamoDB’s data model and API are AWS-specific and demand up-front access-pattern design. Aurora’s instance + storage + I/O pricing and DynamoDB’s capacity model both need careful cost modeling.
Google AlloyDB & Cloud Spanner
Strong — GCP Data LayerStrengths: Google’s two-pronged operational story. AlloyDB is a PostgreSQL-compatible managed engine with separated compute/storage, a columnar accelerator for analytics on live transactional data (HTAP), and ML-driven tuning — Postgres compatibility with more headroom than Cloud SQL. Spanner is the original externally consistent, horizontally scalable relational database, offering global ACID transactions with high-availability SLAs — capabilities almost nothing else matches. Considerations: Both are GCP-only. Spanner carries a premium and a distributed-systems learning curve, and its SQL and operational model differ from a classic single-node RDBMS — overkill unless you truly need global consistency at scale. AlloyDB’s deepest features are Google-specific even though the Postgres wire protocol aids portability.
CockroachDB
Strong — Distributed SQLStrengths: Cloud-neutral distributed SQL with PostgreSQL wire compatibility, survivable across nodes, zones, and regions, with built-in geo-partitioning to pin data to a locality for residency or latency. Multi-active and horizontally scalable while preserving serializable transactions — Spanner-like resilience without committing to a single cloud, available self-hosted or as a managed cloud. Considerations: In 2024 Cockroach Labs retired the open-source Core edition and moved to a single enterprise license (source-available), free only for individuals and companies under a revenue threshold — a real change that pushed some open-source users away. Distributed-SQL latency and transaction-contention behavior differ from a single node and require schema design for the topology; it’s more than most single-region apps need.
Couchbase (Capella)
Strong — Multi-Model NoSQLStrengths: A distributed NoSQL platform that fuses JSON document storage with an in-memory key-value cache, a SQL-like query language (SQL++), and built-in full-text, analytics, eventing, and edge sync via Couchbase Mobile/Lite — useful when you need both document flexibility and memory-speed reads in one system. Capella is the managed DBaaS. Now privately held after its 2025 take-private by Haveli Investments. Considerations: Smaller community, talent pool, and ecosystem than MongoDB or the relational mainstream. The multi-service architecture is powerful but adds operational and sizing complexity. The recent take-private adds some roadmap-direction uncertainty to weigh in a long-lived platform decision. Best value appears at the scale and edge-sync use cases it’s built for.
Redis / Valkey
Strong — In-MemoryStrengths: The de facto in-memory data store for caching, sessions, rate-limiting, queues, and leaderboards, with microsecond-class latency and rich data structures. After community backlash to the 2024 relicensing, Redis 8 (2025) added the OSI-approved AGPL and folded in JSON, search, time-series, and vector sets; the Linux-Foundation Valkey fork remains BSD-licensed and is backed by AWS, Google, and Oracle. Both are available as managed services (ElastiCache, Memorystore, Redis Cloud). Considerations: Primarily a complement to a system of record, not a durable primary database for most use cases — persistence and clustering exist but memory-first means cost scales with dataset size. The 2024–2025 license churn fragmented the ecosystem: Redis Inc. (AGPL/source-available) vs. Valkey (BSD), and you should choose a lane deliberately. Major Linux distributions now ship Valkey by default.
How much should you budget for Enterprise Database Platforms?
Budgeting for an enterprise database platform involves considering license versus consumption models. Proprietary engines like Oracle and SQL Server use per-core or per-named-user licenses, while open engines (PostgreSQL, MySQL) have no license fees but incur costs for managed services or self-hosting infrastructure. Cloud-managed databases like Amazon Aurora, DynamoDB, Google AlloyDB, and Spanner meter on compute, storage, I/O, and data transfer, with egress costs being a significant factor.
Database economics split along two axes: license vs. consumption, and self-managed vs. managed service. Proprietary engines (Oracle, SQL Server) price on a license metric — per-core or per-named-user — that you pay whether or not the capacity is busy, and that drives audit exposure. Open engines carry no license fee but you pay for the people and infrastructure to run them, or for a managed service that bundles both. Cloud-managed databases meter on some mix of compute, storage, I/O, and data transfer, and the headline rate matters less than the unit you scale on. Model the total against your real workload — and price in egress, because that is what makes a proprietary cloud engine expensive to leave.
| Vendor / Engine | Pricing Model | Relative Tier | Key Cost Drivers |
|---|---|---|---|
| Oracle Database | Per-processor or Named-User-Plus license + support; OCPU/ECPU consumption on Autonomous | Premium | Edition and priced options (RAC, partitioning, multitenant), core/processor counts, Software Update & Support, and audit-driven true-ups |
| Microsoft SQL Server / Azure SQL | Per-core license (Std vs. Ent) + Software Assurance; vCore/DTU consumption on Azure SQL | Moderate–Premium | Edition tier, core count, SA, Azure Hybrid Benefit offset, and service tier (Hyperscale waives the SQL license fee) |
| PostgreSQL | No license fee; pay for managed service or self-host + support | Lower | Managed instance size, storage and IOPS, replicas/HA, backups, and any third-party enterprise support (EDB, Crunchy) |
| MySQL | Open-source (GPL) free; commercial editions / HeatWave on a subscription or consumption basis | Lower | Managed instance size, replicas, HeatWave nodes if used, and support edition |
| MongoDB Atlas | Consumption (per-hour cluster tier) for Atlas; subscription for Enterprise Advanced | Moderate–Premium | Cluster tier and node count, data volume and transfer, dedicated search/vector nodes, backup retention, cloud and region |
| Amazon Aurora & DynamoDB | Aurora: instance or Serverless v2 capacity + storage + I/O. DynamoDB: on-demand or provisioned capacity + storage | Moderate–Premium | Compute (ACU/instance) or request/capacity units, storage, I/O and replicated writes, Global Tables, and data egress |
| Google AlloyDB & Spanner | Consumption: vCPU/memory + storage (AlloyDB); compute (processing units/nodes) + storage (Spanner) | Moderate–Premium | Provisioned compute, storage, replicas/read pools, multi-region footprint, and network egress |
| CockroachDB | Enterprise license (free under a revenue threshold); managed cloud on consumption or capacity | Moderate–Premium | vCPU/request-unit consumption, storage, number of regions/replicas, support tier, and revenue-based license eligibility |
| Couchbase (Capella) | Subscription / managed DBaaS by capacity and service group | Moderate | Node/compute and RAM, which services are enabled (data, query, search, analytics, eventing), data volume, and support |
| Redis / Valkey | Open-source free (Valkey BSD; Redis 8 AGPL); managed cache priced by node/memory | Lower–Moderate | In-memory dataset size, node count and HA replicas, throughput, and managed-service tier (ElastiCache, Memorystore, Redis Cloud) |
How long does implementation take for Enterprise Database Platforms?
Implementing an enterprise database platform typically takes 6-9 months. The process begins with assessing and choosing a platform (Months 1-2), followed by schema and data migration (Months 2-4). Validation and cutover occur during Months 4-6, with stabilization and optimization completing the process by Month 9.
Sequence a database migration around the cutover, because that is where the risk concentrates. Schema conversion and bulk loading are the easy parts; keeping the new engine in sync with the old one and switching production traffic with minimal data loss is the hard part. Prove the data path on a low-stakes service before you move the system of record.
Profile the workload — data model, query mix, write concurrency, consistency and residency needs — and map it to a data model and engine. Score shortlisted engines against the weighted criteria, read the actual license, and run a POC that includes a failover and a representative migration. Decide self-managed vs. managed and lock the target topology.
Convert schema and stored logic (watch dialect and data-type gaps), refactor app data-access code and ORMs, and establish change data capture / logical replication from source to target. Bulk-load, then keep the two in sync. Stand up HA, backups/PITR, monitoring, and security (encryption, RBAC, audit) before any cutover.
Run the new engine in parallel: shadow reads, data-parity reconciliation, and load/soak testing at production scale. Rehearse the cutover and the rollback. Migrate a non-critical service first, then the system of record during a planned window, with the replication stream enabling a fast fall-back if parity or performance regresses.
Tune indexes, query plans, and connection pooling under real traffic; right-size instances and storage and reconcile spend against the model. Operationalize day-2 work (vacuum/compaction, patching, major-version upgrades, DR drills), decommission the source engine, and reclaim its license and support costs.
What should you ask vendors about Enterprise Database Platforms?
Use this checklist to pressure-test each shortlisted engine against how it will actually be run — data model, operations, license, and exit — not just its feature sheet.
Frequently asked questions about Enterprise Database Platforms
When is a managed PostgreSQL solution like RDS or Aurora genuinely sufficient, rather than needing a more complex Distributed SQL option like Spanner or CockroachDB?
Managed PostgreSQL is sufficient for new transactional applications with conventional relational data and no extreme scale. Most applications scale far on one large managed Postgres with read replicas before needing the complexity of Distributed SQL, which is typically reserved for situations requiring globally distributed writes with strong consistency and horizontal scale.
Given the licensing changes, how should we choose between Redis and Valkey for in-memory caching, sessions, or leaderboards?
Choose Redis if its AGPL license (from Redis 8) is acceptable, or Valkey if you require a BSD-licensed, OSI-recognized open-source option. Both are drop-in for most caching uses, but the license fork is a deliberate choice, especially if you ship or host software.
What are the hidden costs or audit risks associated with Oracle Database that might surprise a buyer accustomed to other platforms?
Oracle Database has notoriously aggressive compliance reviews and audit-driven true-ups, beyond its per-processor or Named-User-Plus license and support. Costly options like RAC, partitioning, and multitenant features also add significant expense, making it the most expensive and license-audited platform.