Data and persistence
Corporate Oracle is the reality of most of what I maintain. Working well in it, respecting legacy schema, transactions and volume, shapes my day more than any other technology on my list.
Where each one shows up
Oracle is the database behind most of what I touch, and that is why it comes first here. MongoDB comes in where the model is not relational, PostgreSQL in the newer systems, and TimescaleDB shows up a little, in the telemetry time series of the industrial monitoring.
For access, Entity Framework Core is the default, and Dapper comes in where the query needs to leave the ORM: a heavy report, a join EF does not handle well, a procedure that already existed before me.
Oracle, and why it comes first
Résumés usually list databases at the end, in alphabetical order, as if they were an implementation detail. In my case it is the opposite: the biggest design constraint in the landscape is the shared corporate Oracle. The schema is not mine, the table I read is also read by another system, and a column change needs agreement between teams.
What that demands in practice:
- Working in a legacy, shared schema, respecting whoever else depends on it
- Writing analytical queries over volume without bringing the table into the application’s memory
- Reading execution plans and fixing bad queries
- Taking care of transactions that cross more than one table, with correct rollback
- Keeping database compatibility during an application version migration
- Living with multiple schemas from different domains on the same instance
EF Core and Dapper, in the same project
Writes go through the ORM, because there the domain model drives persistence: change tracking, unit of work and entity state transitions beat hand-written SQL. Heavy reads go through direct SQL, because there the query is the product and needs to be reviewable line by line: a report, a dashboard, an extraction for reconciliation, or a query that needs an Oracle feature the ORM does not expose well.
Having both in the same project is choosing the tool per case, not per doctrine.
What I watch for in EF Core: queries that generate N+1 without warning, tracking turned off for what is read-only, schema migration on a shared database where the application cannot always alter the table, and mapping value objects to existing columns of a legacy schema.
MongoDB and PostgreSQL
They are the databases of what is being born now, in a landscape where Oracle dominates the legacy.
MongoDB when the document naturally has no fixed schema: an integration payload that varies by partner, a processing log record, data whose shape the supplier changes without warning. The trap I avoid is using it as a relational database in disguise: if the query needs a join, the data was in the wrong database.
PostgreSQL when the system is new and has no obligation to live with the corporate schema.
TimescaleDB, for time series
A PostgreSQL extension used in Industrial monitoring. A machine on the shop floor emits events continuously, and storing that in an ordinary relational table works for a few weeks before the dashboard query starts to take long: the volume grows in a single dimension, time, and a traditional index does not help as much as it seems.
What the extension adds, keeping SQL and tooling: hypertables with automatic partitioning by time, retention policies and continuous aggregates. It is what let the dashboard answer quickly over a long window.
Where I applied it
Payments and anti-fraud · Industrial monitoring · Commissions
Experience · Manufacturer reporting
What I have not done yet
I am not a DBA. I read execution plans and know how to fix a bad query, but fine instance tuning, partitioning and replication are someone else’s territory. I have not worked with a data warehouse of my own or with data pipelines at analytical scale. In TimescaleDB my experience is small and recent: I know how to model hypertables, retention and continuous aggregates, without mileage operating it at scale.