YUGABYTEDB · INDEPENDENT ENGINEERING
Assess, design and operate self-managed YugabyteDB for workloads that need PostgreSQL-compatible SQL across zones or regions, with migrations and recovery tested against your own workloads.
Independent YugabyteDB engineering.
These are independent Bassirah engineering and support offerings. They do not imply upstream vendor or foundation endorsement, official vendor support rights, enterprise feature entitlement or maintenance guarantees.
YugabyteDB is a trademark of YugabyteDB, Inc. Bassirah is not a partner of YugabyteDB, Inc.
Supported releases.
YugabyteDB is developed by YugabyteDB, Inc. and its community. The core database is released under the Apache License 2.0. Bassirah provides independent engineering for the v2025.2 long-term support (LTS) release series and the v2026.1 standard-term support (STS) release series, and plans upgrades for universes on earlier series. The exact versions in scope are named in each statement of work. Last reviewed: 23 October 2026.
| Release series | Status on 23 October 2026 | How Bassirah treats it |
|---|---|---|
| v2026.1 (STS) | First released 29 June 2026; latest release v2026.1.2.0, 22 September 2026 | Supported where you accept the shorter STS maintenance window and the upgrade cadence it implies |
| v2025.2 (LTS) | First released December 2025; latest release v2025.2.7.0, 5 October 2026 | Default target for new production deployments and upgrades |
| v2025.1 (STS) | First PostgreSQL 15-based stable series, July 2025 | Upgrade planning to v2025.2 or v2026.1 |
| v2024.2 (LTS) and earlier | PostgreSQL 11-based; latest v2024.2 release v2024.2.11.0, 25 August 2026 | Upgrade assessment: moving to a PostgreSQL 15-based series requires additional upgrade steps |
WHY IT MATTERS
YugabyteDB distributes data and transactions across nodes, zones and regions while offering a PostgreSQL-compatible SQL interface, so teams can scale out and tolerate failures without sharding the application themselves.
Its YSQL interface reuses the PostgreSQL query layer, and the current stable series are based on PostgreSQL 15. Underneath, data is split into shards that are each replicated with the Raft consensus protocol, and transactions span shards and nodes. That design changes the rules for schema keys, query plans, latency between zones and failure handling. Workloads that run well on a single PostgreSQL primary can behave differently once data and transactions are distributed. Bassirah tests that behavior with your own schema and workload before you commit, and engineers the deployment so that it holds up in production.
WHAT BASSIRAH DELIVERS
FIT FIRST
A distributed database adds moving parts. We recommend YugabyteDB when the workload needs what it provides, and we say so when a well-run PostgreSQL deployment is enough.
| Requirement | YugabyteDB is worth evaluating when… | PostgreSQL alone is often enough when… |
|---|---|---|
| Scale | Write volume or data size is growing beyond what one primary can serve, and you want to scale out by adding nodes | One primary with read replicas and connection pooling serves the workload with headroom |
| Availability | The service must keep accepting writes when a node or a whole zone fails, without a manual failover step | A tested failover of a primary to a replica meets your recovery objectives |
| Geography | Data must stay in, or be served from, several regions with a single SQL interface | Users and data sit in one region |
| Application changes | You can test the application against YSQL and adjust schema keys, transactions and queries where behavior differs | The application depends on PostgreSQL features or extensions that you cannot change or test |
| Operations | Your team, or a contracted provider, will operate a distributed system | You want the smallest possible operational footprint |
Considering PostgreSQL instead? See our PostgreSQL engineering page. Compatibility differences between YSQL and PostgreSQL must be tested for each workload: we never assume an application will run unchanged.
TOPOLOGY AND RESILIENCE
YugabyteDB replicates each shard with Raft consensus inside a universe, can replicate asynchronously between universes with xCluster, and can serve reads from read replicas. Each option trades latency, cost and consistency differently. We choose them per workload, then prove the effect of a node, zone or region failure in tested recovery exercises against objectives you approve.
| Decision | Typical approach | Trade-off we make explicit |
|---|---|---|
| Replication within a universe | Raft-replicated shards spread across zones or regions, with the replication factor set per design | Write latency between zones or regions vs. tolerance of zone or region loss |
| Leader placement | Preferred leaders close to the application, so most reads and writes stay local | Lower local latency vs. behavior and latency after a leader moves |
| Replication between universes | xCluster asynchronous replication, one-way or two-way, between two universes | Independent universes and lower write latency vs. data that is not yet replicated at the moment of failure |
| Read scaling | Read replicas in remote regions for reads that can accept slightly older data | Local read latency vs. data freshness |
| Recovery from data loss or error | Distributed backups to separate object storage, with point-in-time recovery where configured | Storage cost vs. how far back and how precisely you can restore |
OPERATIONS
Choose hash or range sharding and primary keys so data spreads evenly and the queries that matter read from as few shards as possible.
Analyze execution plans for the statements that consume the most time, reduce cross-node round trips and add or change indexes based on evidence.
Rolling upgrades with compatibility checks for drivers, extensions and tooling, rehearsed in staging with a rollback decision point.
Node health, tablet balance, replication lag and slow queries with actionable alerts, plus backup schedules with restore drills.
MIGRATION
Delivered through our migration and modernization practice, from PostgreSQL or from other relational databases.
Start with a compatibility test on your own schema and workload.
USE CASES
Transactional services that need to keep serving reads and writes through node or zone failures.
Applications serving users in several regions, with data placement designed for latency and data-residency requirements.
PostgreSQL workloads that need to scale out, after compatibility testing confirms the move is worth it.
SUPPORT ROUTES
The YugabyteDB core database is open source. YugabyteDB, Inc. also offers its own commercial products and support: YugabyteDB Anywhere, a self-managed platform for operating universes, and YugabyteDB Aeon, a managed database service. Bassirah supports the open-source database independently and is clear about where its commitments end.
| Decision factor | Community only | Bassirah independent support | Vendor contract with YugabyteDB, Inc. |
|---|---|---|---|
| Who operates YugabyteDB | Your team | Your team with Bassirah engineering, or Bassirah under a managed scope | Your team with YugabyteDB Anywhere, or the vendor for YugabyteDB Aeon, under the vendor's terms |
| Help with incidents | Public community channels, no response commitment | Response targets per your agreement | Vendor support under the vendor's own terms |
| Code defects | Reported by you to the project | Reproduced, worked around and reported upstream by Bassirah | Handled by the vendor under its terms |
| Upstream fixes and releases | On the project's timeline | On the project's timeline; we track them, test them and apply them through change control | Under the vendor's terms |
| Commercial products | Not included | Not included: Bassirah does not resell or license YugabyteDB Anywhere or YugabyteDB Aeon | Contracted directly with YugabyteDB, Inc. |
If you need vendor-backed support, YugabyteDB Anywhere or YugabyteDB Aeon, that is contracted with YugabyteDB, Inc. How cases, severities and response targets work for our independent support is set out in our open-source support model. For fully contracted operations, see Managed Services.
WORKS WITH
YugabyteDB is one option in our operational database practice. We place it alongside PostgreSQL, Cassandra and caching where each fits, and test every integration first.
A single-primary PostgreSQL deployment, when it meets the scale and availability objectives with less to operate.
A wide-column alternative for known, partition-based access patterns. YCQL has Cassandra roots, but compatibility must be tested per application.
Low-latency caching and session state in front of the database, where measurements justify it.
Contracted operations, monitoring and incident handling for YugabyteDB estates.
Yes. The core database is released under the Apache License 2.0. YugabyteDB Anywhere is licensed separately and YugabyteDB Aeon is a managed service; both are commercial products of YugabyteDB, Inc. Bassirah supports the open-source database and is not endorsed by YugabyteDB, Inc.
Not automatically. YSQL reuses the PostgreSQL query layer, and current stable series are based on PostgreSQL 15, but a distributed database behaves differently in areas such as keys, query plans, latency and some features and extensions. We test your schema, code and workload before recommending a move.
When one primary with replicas meets your scale and recovery objectives, when users and data sit in one region, or when you depend on features you cannot test against YSQL. A well-run PostgreSQL deployment is simpler to operate. See our PostgreSQL page.
We work on the v2025.2 LTS and v2026.1 STS release series, and we plan upgrades for universes on earlier series, including PostgreSQL 11-based v2024.2 universes, which need additional steps to move to a PostgreSQL 15-based series. The versions in scope are confirmed in each statement of work.
No. Bassirah is not a YugabyteDB, Inc. partner and does not provide vendor support, vendor security fixes or vendor escalation. Our services are independent engineering and support, with scope and response targets defined in your agreement. Code fixes and releases follow the project’s timeline. See our support model.
Yes. A universe can span zones or regions with Raft replication, two universes can be linked with xCluster asynchronous replication, and read replicas can serve reads in remote regions. Each choice trades latency against consistency and cost, so we design it for your objectives and test the effect of losing a zone or region.
Tell us about your workloads, topology and recovery objectives. We will scope a fit assessment and a practical next step.
Architecture Patterns
Synchronous replication, geo-partitioning, xCluster and read replicas solve different problems. What each does, what it costs and how to choose.
YugabyteDB
Operations & Reliability
v2024.2, the last PostgreSQL 11-based LTS series, leaves maintenance in December 2026. How to choose a target series and plan the YSQL major upgrade.
YugabyteDB
Read article : YugabyteDB LTS and STS Releases: Upgrade Planning and the PostgreSQL 15 Path→
Comparisons & Decisions
YSQL reuses the PostgreSQL query layer, but it is not a drop-in replacement. How to test compatibility, redesign the schema and choose a migration route.
PostgreSQLYugabyteDB
