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.
SOLUTION CONCEPT
Solution Concept: Streaming Operational Events into Analytics with Apache Kafka and Apache Flink
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
Transactional services emit business events such as orders, payments or device readings. Operational dashboards are refreshed by hourly or nightly extracts from the production database, so teams see problems after the fact, and every new reporting query adds load to the system that serves customers. Several teams want the same events for different purposes, and each has started building its own point-to-point feed with its own copy of the data and its own idea of what an event means.
How Bassirah Would Approach It
- Confirm the fit firstEstablish which decisions need fresher data, and how fresh. Where scheduled micro-batch loads meet the objectives, we recommend them over a streaming platform, which adds components to operate.
- Design the event backboneModel topics, keys and partitions around business entities on Apache Kafka, define event schemas and how they may evolve, and agree retention, replay and delivery semantics for each stream. Use change data capture where services cannot publish events directly.
- Add stream processing only where neededUse Apache Flink for stateful steps such as enrichment, deduplication and windowed aggregation, with checkpoints, state size and late-event handling designed explicitly. Simple transformations stay in the ingestion path or the analytical store.
- Serve analytics separatelyLoad events into an analytical store chosen for the query patterns, such as ClickHouse, so dashboards no longer query the production database. The support route for each component is decided per workload.
- Prove it, then plan operationsRun representative event rates, broker and processing failures, consumer restarts and schema changes in a proof of concept, 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 |
|---|---|
| End-to-end freshness | Time from event creation to availability in dashboards, per data product, under representative load |
| Throughput | Sustained and peak event rates at the volume you forecast, with headroom agreed in advance |
| Delivery semantics | Duplicates, gaps and ordering per stream, checked by reconciliation against source records |
| Failure behavior | Time until processing resumes and catches up after a broker, Flink job or consumer failure, with state restored from checkpoints |
| Replay | Reprocessing a defined period from retained events without corrupting downstream tables |
| Schema evolution | A compatible and an incompatible schema change taken from producer to dashboard, with the incompatible change blocked |
| 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 open-source engineering for Apache Kafka and Apache Flink and does not resell a commercial distribution of either. Apache Kafka engineering → · Apache Flink engineering → · Real-Time Analytics →
Planning a streaming analytics platform?
Start with a fit assessment on your own event sources and query patterns.
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.