CASE STUDIES
Verified Outcomes, Told Transparently.
Every Bassirah case study follows the same structure: the challenge, the architecture, the services we delivered and the outcome that was measured. We publish a story only after the customer has approved it in writing.
HOW WE PUBLISH
Four Parts. Every Story. No Exceptions.
We use one structure so you can compare stories and judge how each one relates to your own environment.
- ChallengeThe business and technical problem, the existing data landscape and the constraints the customer faced.
- ArchitectureThe design we arrived at, which technology took which responsibility, and the alternatives we ruled out.
- ServicesWhat Bassirah delivered: advisory, implementation, migration, optimization, managed operations or enablement.
- Measurable outcomeWhat changed, how it was measured, over what period and against which baseline.
Every case study is reviewed and approved in writing by the customer before publication. Figures are published only where they were measured and approved.
Customer Stories
Verified case studies will appear here.
We publish customer stories only with written approval, so this library grows at our customers’ pace. In the meantime, our architects can walk you through relevant reference architectures and the deliverables a typical engagement produces.
SOLUTION CONCEPT
Solution Concept: Scaling a PostgreSQL Application Across Regions with YugabyteDB
How we would approach a request we often discuss, written so you can judge our method before you talk to us. It is not drawn from a specific project.
Solution concept, not a customer story.
This is a solution concept, not a customer story. It describes how Bassirah would approach the engagement; no client, results or metrics are implied.
The Challenge
A transactional application runs on a single PostgreSQL primary. Write volume and data size keep growing, the business wants the service to keep accepting writes if a zone fails, and users in a second region need local access with data placed to respect residency requirements. Read replicas and connection pooling help reads but not the write path, and sharding the application by hand would push distribution logic into every service.
How Bassirah Would Approach It
- Confirm the fit firstTest whether a tuned PostgreSQL deployment, with read replicas, partitioning and a tested failover, can meet the objectives. We recommend YugabyteDB only where it cannot.
- Assess compatibilityRun the schema, procedural code, extensions and representative queries against YSQL on a supported release series, and list what runs unchanged, what needs rework and what needs a different design.
- Design the universeChoose zones and regions, the replication factor and preferred leader placement near the application, decide whether xCluster replication or read replicas are needed, and redesign primary keys and indexes for distribution.
- Prove it in a proof of conceptRun representative workloads, inject node and zone failures, and rehearse backup and restore against objectives you approve.
- Plan migration and operationsSynchronize data, run in parallel with reconciliation, rehearse the cutover with rollback decision points, then hand over runbooks or move to contracted managed support.
What We Would Measure in a Proof of Concept
| Measure | How it would be measured |
|---|---|
| Compatibility | Schema objects, procedures and queries that run unchanged, need rework or need a redesign, recorded per item |
| Latency per region | p95 and p99 latency of the key transactions from each region, compared with the current PostgreSQL baseline |
| Throughput | Sustained transactions at the concurrency you forecast, with headroom agreed in advance |
| Failure behavior | Errors, retries and the time until writes resume when a node or a zone is taken down |
| Replication lag | Lag of xCluster replication or read replicas, where they are part of the design |
| Backup and restore | A timed restore drill, including point-in-time recovery where configured, against objectives you approve |
| Operational effort | Upgrade, scaling and monitoring tasks rehearsed by your team, with gaps recorded |
These are the measures we would agree before a proof of concept starts, not results. Acceptance thresholds are set with your team for your workload. Bassirah provides independent engineering for YugabyteDB and is not a partner of YugabyteDB, Inc. YugabyteDB engineering → · PostgreSQL engineering →
Considering distributed SQL for a PostgreSQL application?
Start with a fit assessment on your own schema and workload.
EXPLORE NOW
See How We Work Before You Talk to Us
Reference architectures
Practical patterns that explain the problem, the design choices, each technology’s responsibility and a route to proof of concept.
Engineering insights
Version-scoped articles on choosing and operating data, analytics and AI platforms.
A private workshop
Map a pattern to your environment in a discovery workshop or architecture review.
Case studies describe specific projects delivered under specific conditions. Results depend on workloads, data, infrastructure, operating model and the product versions in use, and are not a guarantee of results in other environments. Product names and trademarks belong to their respective owners. Mention of a technology in a case study does not imply endorsement by its vendor or project maintainers.
About Our Case Studies
Why are there so few case studies?
We publish only stories that a customer has approved in writing, with outcomes that were actually measured. Many enterprise and public-sector customers restrict publicity, so the library grows only as approvals are granted.
Do you publish anonymized case studies?
Only when the customer approves the anonymized text in writing. Anonymization never means invention: the challenge, architecture, services and results must all come from a real, documented project.
Related Pages
Let's Define What Success Looks Like for You.
Every engagement starts with documented objectives and acceptance criteria. Tell us your challenge and we will propose a measurable first step.