Elke applicatie die data opslaat, is voor correctheid, snelheid en betrouwbaarheid afhankelijk van de databaselaag: een schema dat het domein goed modelleert, queries die ook bij productievolumes snel zijn, indexen die die queries mogelijk maken, transacties die de data consistent houden, en migraties die het schema veilig laten meegroeien.
Database engineering is geen bijzaak voor als de applicatie eenmaal werkt. Keuzes in het schema hebben gevolgen die zich gedurende de hele levensduur opstapelen: de ontbrekende index die bij testdata geen probleem is maar in productie een incident wordt, of het datatype dat bij financiële bedragen afrondingsfouten geeft. Wij ontwerpen en bouwen databaselagen met PostgreSQL en MySQL als relationele databases en Redis voor caching, sessies en realtime data.
Wat database engineering omvat
Schema-ontwerp. Tabellen, kolommen en relaties die het domein weerspiegelen, genormaliseerd waar dat telt en bewust gedenormaliseerd waar het moet. De juiste datatypes, zoals NUMERIC in plaats van FLOAT voor bedragen en tijdstempels met tijdzone. Constraints die de data bewaken, los van de applicatiecode: NOT NULL, UNIQUE, CHECK en foreign keys. En een bewuste keuze voor primaire sleutels, van oplopende integers tot tijd-sorteerbare UUID's.
Indexstrategie. B-tree-indexen in de juiste kolomvolgorde, partiële indexen voor alleen de relevante rijen, indexen op expressies zoals LOWER(email), en GIN-indexen voor JSON en full-text search. Met EXPLAIN ANALYZE controleren wij of de planner de indexen echt gebruikt en waar de tijd zit.
Query-optimalisatie. Joins die de planner kan optimaliseren, een bewuste keuze tussen subqueries, CTE's en joins, window functions voor lopende totalen, rangschikkingen en vergelijkingen met vorige rijen, en aggregaties die het rapportagevraagstuk direct in de database beantwoorden in plaats van in applicatiecode.
Transacties en gelijktijdigheid. Het juiste isolatieniveau per situatie, expliciete locks met SELECT FOR UPDATE waar updates niet verloren mogen gaan, een vaste volgorde van locks om deadlocks te voorkomen, en optimistische concurrency met versiekolommen waar conflicten zeldzaam zijn.
Migraties. Schemawijzigingen als versiebeheerde migraties, met tooling die past bij de stack: sqlx-cli voor Rust, EF Core voor C#, Prisma of Drizzle voor TypeScript, Alembic voor Python. Veilige patronen voor wijzigingen zonder downtime, met de expand-contract-aanpak voor wijzigingen die draaiende code anders zouden breken.
PostgreSQL-specifiek. JSONB voor semi-gestructureerde data, ingebouwde full-text search, TimescaleDB voor tijdreeksen, LISTEN/NOTIFY voor lichte realtime notificaties, en partitionering voor tabellen die te groot worden voor bewerkingen op de hele tabel.
Connection pooling en monitoring. PgBouncer en goed ingestelde pools in de applicatie, en pg_stat_statements om de queries te vinden die de meeste tijd kosten voordat ze een probleem worden.
Redis voor caching en realtime data
Redis gebruiken wij waar een relationele database niet de juiste plek is: data die in microseconden beschikbaar moet zijn, data die na een tijd vervalt, of resultaten van dure berekeningen die worden hergebruikt. Denk aan cache-aside en write-through caching met duidelijke sleutels en vervaltijden, sessies die over meerdere applicatie-instanties werken, sorted sets voor ranglijsten, pub/sub voor realtime berichten, lijsten als werkwachtrij, en HyperLogLog voor het schatten van unieke aantallen.
Gebruikte technologieën
PostgreSQL, MySQL en MariaDB, Redis, TimescaleDB, PgBouncer, Flyway en Liquibase, Alembic, sqlx, EF Core, Prisma en Drizzle, pg_stat_statements en EXPLAIN ANALYZE, AWS RDS en Aurora, en Docker voor ontwikkel- en testdatabases.
Een datalaag die meegroeit
Een goed ontworpen databaselaag bedient de applicatie vandaag efficiënt, kan veilig meegroeien als de eisen veranderen, en wordt niet de bron van de prestatie- en integriteitsproblemen die een ondergeëngineerde database na verloop van tijd veroorzaakt.
Veelgestelde vragen over SQL en database engineering
Kunnen jullie onze trage database versnellen?
Meestal wel. Wij analyseren de traagste en meest uitgevoerde queries met EXPLAIN ANALYZE en pg_stat_statements, en verbeteren daarna indexen, queries of schema waar de tijd werkelijk verloren gaat.
PostgreSQL of MySQL?
PostgreSQL is onze standaard voor nieuwe projecten vanwege de mogelijkheden en betrouwbaarheid. MySQL of MariaDB blijft een goede keuze waar uw stack of hosting die al gebruikt.
Kunnen schemawijzigingen zonder downtime?
Ja, met veilige migratiepatronen: eerst toevoegende wijzigingen, indexen die concurrent worden opgebouwd, en de expand-contract-aanpak voor wijzigingen die anders draaiende code zouden breken.
Is de broncode van ons?
Dat kan. Het eigendom van de broncode wordt contractueel vastgelegd, en de code kan volledig van u zijn, inclusief documentatie en tests.
Bekijk alle technologieën waarmee wij werken of onze software op maat.