My data-platform experience did not begin with one clean, modern stack. It grew across systems built in different eras and for very different reasons: UniVerse multi-value databases and Pick BASIC applications, SQL Server, MySQL, PostgreSQL, Firebase Realtime Database, and Firestore.
At first glance, these technologies can seem like separate worlds. A multi-value database organizes information differently from a normalized relational schema. A real-time cloud datastore encourages different read patterns again. After working with all three, I have become less interested in arguing that one model is universally better and more interested in understanding the workload each one must support.
Start with how the business uses the data
A schema is not just a technical artifact. It reflects the questions a business asks and the operations it performs every day.
In mature UniVerse systems, data structures are often closely tied to established business workflows. Multi-valued fields can represent relationships compactly, and years of Pick BASIC programs may depend on exact record layouts. That design can feel unfamiliar to someone coming from SQL, but changing it without understanding the surrounding processes is risky.
Relational systems make different promises. Tables, keys, constraints, and transactions provide a clear way to protect consistency. They also make it natural to combine data through joins and support operational reporting with views, stored procedures, and carefully designed queries.
Neither model removes the need to understand the business. Before changing a database, I want to know which workflows write the data, which reports depend on it, and what “correct” means to the people using the system.
Normalization and duplication are tradeoffs
In SQL Server, MySQL, or PostgreSQL, I generally begin with a normalized model. It reduces accidental duplication, keeps updates consistent, and gives the database a strong foundation for transactional work.
But normalization is not a contest. A highly fragmented schema can make simple reads expensive and difficult to understand. Sometimes a summary table, cached value, or purpose-built read model is the practical answer—provided that its source of truth and update rules are explicit.
That becomes especially important with Firebase. For a real-time application, I have used MySQL as the transactional source of truth while publishing denormalized read models to Firebase Realtime Database. The duplicate data exists for a reason: it gives clients a fast structure to subscribe to. The difficult part is not creating the copy; it is designing synchronization, recovery, and concurrency behavior so the copy remains trustworthy.
Indexes should follow real queries
Adding an index because a column “looks important” is rarely enough. I prefer to begin with an actual slow query and its execution plan.
The useful index depends on filter conditions, join columns, sort order, selectivity, and the data distribution in production. An index that speeds up one report also adds storage and makes inserts or updates more expensive. Too many indexes can be their own performance problem.
The same principle applies beyond relational databases. Firestore composite indexes and Firebase key structures are shaped by the reads the application must perform. If the datastore cannot answer an important query efficiently, the data model may need to change.
Migrations need operational planning
Moving data between systems is not finished when the rows arrive.
I account for type differences, identifiers, null behavior, dates, text encoding, relationships, record counts, and application downtime. For large transfers, batching, compression, resumability, and validation matter. I also want a rollback or reconciliation plan before the migration begins.
The most useful validation compares business meaning, not only file size or row count. Do financial totals still match? Can users find the same customers? Do the reports reconcile? Can the application safely resume after an interrupted batch?
Choose the database with the whole system in mind
The right datastore depends on consistency requirements, query patterns, latency, scale, operating cost, team experience, and the cost of failure.
SQL is a strong default for transactional systems and flexible reporting. A real-time datastore can be an excellent read layer for collaborative interfaces. A mature multi-value platform may continue delivering substantial business value even when its model is no longer fashionable.
Experience across these systems has taught me not to confuse unfamiliarity with poor design—or novelty with the right design. Good database architecture begins with the workload, makes tradeoffs visible, and protects the integrity of the business data over time.