Open Source Amazon Aurora Alternatives

TiDB is a cloud-native distributed SQL database designed for high availability, horizontal and vertical scalability, strong consistency and performance under load. It removes the usual choice between a single node that eventually runs out of room and a sharded arrangement that gives up proper transactions.

Compatibility with MySQL 8.0 means familiar protocols, frameworks and tools keep working, and applications migrate with no code changes or minor ones, helped by a suite of data migration tools. The architecture separates computing from storage, so each side scales independently and without downtime.

A few design decisions define how the database behaves in production.

• ACID transactions: a two-phase commit protocol keeps transactions correct across nodes despite network partitions or node failures.
• Raft consensus: data lives in several replicas and a transaction commits only after a majority write, with automated failover.
• Two storage engines: TiKV holds rows and TiFlash holds columns, replicated in real time so analytics read consistent data.
• Query coordination: the TiDB server plans execution across both engines and sends each part of a query to the one that suits it.
• Replica placement: replicas can be positioned geographically to match a chosen level of disaster tolerance.

Deployment runs in public clouds, on premises or natively on Kubernetes, where TiDB Operator automates cluster operations. All source code including enterprise-grade features carries the Apache 2.0 license, and teams who would rather not operate a cluster can use the managed cloud service or start a local playground to evaluate first.

Separating storage from compute is the whole design of Neon, an open-source serverless Postgres platform that substitutes the PostgreSQL storage layer by redistributing data across a cluster of nodes.

An installation is compute nodes plus the Neon storage engine. The compute nodes are stateless PostgreSQL nodes backed by that engine, which has two major components. A pageserver acts as the scalable storage backend, and safekeepers form a redundant write-ahead log service that stores WAL durably until the pageserver has processed it and uploaded it to cloud storage.

Running it locally shows the shape of the system.

• Pageserver: serves pages to the compute nodes and owns the path out to cloud storage.
• Safekeepers: receive WAL from a compute node and hold it until it has been processed.
• Tenants and timelines: data is organized per tenant, with timelines underneath each one.
• Branches: a timeline can be branched by name and a Postgres endpoint started on that branch.
• neon_local: a CLI starts the pageserver, safekeeper and broker, then creates endpoints for experiments.

Building requires Rust, protoc 3.15 or newer, and a long list of system packages documented for Ubuntu, Debian, Fedora, Arch and macOS. That local path suits small experiments and testing code changes, while the hosted free tier is the quicker way to get a connection string and a client attached.

OceanBase is a distributed relational database developed entirely by Ant Group. It runs on clusters of ordinary servers rather than specific hardware architectures, which takes proprietary appliances out of the conversation when one database node stops being enough.

Availability and scaling both come from the Paxos protocol underneath its distributed structure. Data is replicated so a node failure costs no committed writes, and capacity grows by adding machines to the cluster.

The project states its characteristics in concrete numbers rather than adjectives.

• Transparent scalability: up to 1,500 nodes, petabytes of data and a trillion rows in one cluster.
• Benchmark results: 707 million tmpC on TPC-C and 15.26 million QphH at 30000GB on TPC-H.
• Storage efficiency: a claimed saving of 70 to 90 percent on storage costs.
• Real-time analytics: HTAP workloads served without standing up a separate analytical system.
• Recovery targets: zero data loss and a recovery time under 8 seconds.
• MySQL compatibility: migration from MySQL without rewriting the application layer.

Three routes get an instance running. An all-in-one installer deploys a stand-alone database on Linux, a Docker image starts a mini instance on a single port from Docker Hub, quay.io or ghcr.io, and ob-operator deploys and manages instances inside Kubernetes.

More than 2000 customers across financial services, telecom, retail and internet companies run it, and the source is Apache 2.0 with a public roadmap and developer documentation for compiling your own build.