Database Services: PostgreSQL, MySQL & MongoDB

Database services cover everything that happens between your application and the data it depends on: choosing the right engine, designing the schema, writing queries that stay fast as tables grow, and keeping the whole thing backed up, replicated and secure. When the database is right, nobody notices it. When it is wrong, you see it everywhere – slow pages, timeouts during sales, reports that take minutes, and developers afraid to change a column.

At CodeWiz we design, build, tune and rescue databases for web applications, online stores, SaaS products, APIs and data-heavy internal tools. We work daily with PostgreSQL and MySQL/MariaDB as the system of record, MongoDB for document-shaped data, Typesense for fast search and Redis for caching, queues and real-time data – and we know where each of them belongs and where it does not.

This service is for teams starting a new product who want a data model that will not need a painful rewrite in a year, and for companies whose existing database has become the bottleneck. If your application slows down as data grows, your server CPU sits at 100% during peaks, or nobody is quite sure the backups would actually restore, a database review is usually the highest-leverage fix available.

For design, open-source tools are the default when they fit the job.

PostgreSQL & MySQL Development and Optimization

Relational databases are still the right foundation for most business applications: orders, invoices, users, permissions and anything else where consistency matters. PostgreSQL and MySQL (including MariaDB) are both mature, open-source and fast. The differences matter mostly at the edges, and we pick based on your workload, your framework and your team rather than habit.

A design engagement starts from the system you already run.

PostgreSQL vs MySQL in practice

• PostgreSQL shines with complex queries, strict data integrity, JSONB columns, full-text search, window functions, partial and expression indexes, and extensions such as PostGIS for geodata or pgvector for AI embeddings.
• MySQL/MariaDB is a natural fit for WordPress, WooCommerce, Magento and PrestaShop, has very predictable performance for simple read-heavy workloads, and is supported by practically every hosting provider.
• Both work well with Laravel, Node.js (Prisma, Knex, TypeORM, Drizzle) and every major language, so the choice rarely limits your application code.

Query optimization and indexing

Most “the database is slow” problems are a handful of queries without the right index, N+1 query patterns in the ORM, or a configuration left at installation defaults. We start with data, not guesses: pg_stat_statements or the MySQL slow query log to find the queries that consume the most total time, then EXPLAIN ANALYZE to see why.

The design work stays in your repository and on your infrastructure.

Beyond indexes, we tune memory settings (shared_buffers, work_mem, innodb_buffer_pool_size), add connection pooling with PgBouncer or ProxySQL, fix ORM queries that load whole tables, and remove indexes nobody uses – because every extra index slows down every write. The official PostgreSQL guide to EXPLAIN is an excellent reference if you want to dig deeper.

CodeWiz reviews design in production, not only in a demo.

Typesense & MongoDB: Search and Document Data Done Right

Not every problem is relational. Two tools we regularly add next to a primary SQL database are Typesense for search and MongoDB for flexible, document-shaped data.

Typesense for instant, typo-tolerant search

A LIKE '%term%' query cannot use a normal index, ignores typos and ranks results poorly. Typesense is an open-source search engine that returns results in milliseconds, handles typos, synonyms and faceted filters, and is far lighter to run than Elasticsearch. We keep the SQL database as the source of truth and sync changes into Typesense through model events, a queue or change data capture, so search is fast and never becomes a second, diverging copy of your data. We have written in detail about how we build high-performance search engines with Typesense.

MongoDB where documents fit naturally

MongoDB is a good choice for product catalogues with very different attributes per category, event and log data, content with deeply nested structures, and prototypes where the schema is still moving. We design collections around how the data is read, use schema validation so “schemaless” does not become “anything goes”, build compound indexes that follow the ESR rule (equality, sort, range), and use the aggregation pipeline instead of pulling documents into application code.

We are also honest about the limits: if your data is full of relationships and transactions across entities, PostgreSQL with a few JSONB columns is often simpler than MongoDB plus application-side joins.

Which Database for Which Job

Most applications we build use two or three data stores, each doing what it is best at. This is the comparison we walk clients through when planning an architecture:

Redis Caching in Your Database Architecture

The fastest query is the one that never reaches the database. Redis sits next to your primary database and absorbs repeated reads: product pages, configuration, permission checks, expensive aggregates and API responses. Done well, it cuts database load dramatically and makes response times predictable during traffic spikes.

From a database perspective, our focus is on keeping Redis and the database consistent:

• Cache-aside reads with sensible TTLs, and explicit invalidation when the underlying rows change.
• Stampede protection with locks or early recomputation, so one expired key does not send hundreds of identical queries to the database at once.
• Separate Redis databases or instances for cache (evictable) and for sessions and queues (must not be evicted), with the right maxmemory-policy on each.
• Redis for more than caching: Laravel and BullMQ queues, rate limiting, distributed locks and real-time counters.

Caching across all layers – Memcached, application caches, HTTP and CDN – is a topic of its own, which we cover as a separate caching service.

Database Sharding and Scaling Beyond One Server

Database sharding splits data across several database servers, usually by a shard key such as tenant or customer ID, so no single machine has to hold or serve everything. It is powerful, but it is also the most complex way to scale, and it should come last, not first.

Before sharding, we exhaust the cheaper steps, roughly in this order:

1. Fix slow queries and missing indexes, and add connection pooling.
2. Scale the server vertically – modern hardware with NVMe storage goes a long way.
3. Add read replicas and route reporting and read-heavy traffic to them.
4. Cache hot data in Redis and move search to Typesense.
5. Partition very large tables (for example by month) inside one database.
6. Only then shard – with Citus for PostgreSQL, Vitess for MySQL, or MongoDB’s native sharding.

When sharding is genuinely needed, we design the shard key, the routing layer and the migration path so it can be done without downtime. Our blog post on database sharding vs. partitioning explains the trade-offs in more depth.

Database Design and Data Modeling

A good schema is cheaper than any amount of later optimization. For new projects we model the domain first – entities, relationships, how the data will be queried and how it will grow – and only then write migrations.

• Normalized core tables with proper primary keys, foreign keys and constraints, so invalid data cannot be stored in the first place.
• Deliberate denormalization only where read performance requires it, documented and kept in sync.
• Correct data types: numeric for money instead of floats, timestamptz for time, UUIDv7 or bigint keys depending on the use case.
• Soft deletes, audit columns and multi-tenancy decided upfront, not bolted on later.
• An entity-relationship diagram and data dictionary your team can use for onboarding.

Backups, Replication and High Availability

A backup you have never restored is a hope, not a backup. Every database we manage gets an automated backup strategy with regular, tested restores.

• Point-in-time recovery for PostgreSQL with pgBackRest or WAL-G, and binary-log based recovery for MySQL, so you can restore to the minute before a mistake.
• Encrypted off-site copies in object storage, kept separately from the production server and its credentials.
• Streaming replication with a hot standby, and automatic failover with Patroni or managed database services where uptime targets justify it.
• Monitoring of replication lag, disk growth, long-running queries and locks, with alerts before users notice anything.

For online stores, this ties into a broader approach we describe in zero data loss e-commerce, where every order and customer action must be recoverable.

Database Security and Access Control

• Databases never listen on a public interface; access goes through private networks, VPN or SSH tunnels.
• Separate users per application and role, with least-privilege grants – the web app cannot drop tables.
• TLS for connections, encryption at rest where required, and secrets stored outside the codebase.
• Parameterized queries everywhere to eliminate SQL injection, plus row-level security in PostgreSQL for multi-tenant systems.
• Audit logging and GDPR-friendly handling of personal data, including anonymized copies for development and staging.

Common Database Mistakes We Fix

• No indexes on foreign keys and filter columns, or dozens of overlapping indexes that slow every write.
• ORM N+1 queries that turn one page view into hundreds of database round trips.
• Storing money as floats, dates as strings or comma-separated IDs in a single column.
• Running reports and heavy exports on the same primary database that serves checkout.
• Default configuration on a server with plenty of RAM that the database never uses.
• Backups stored on the same server as the database, never tested.

How We Work

1. Audit: we review the schema, slow query logs, configuration, server metrics, backups and how the application uses the database.
2. Plan: we prioritize findings by business impact and agree on a roadmap – quick wins first, structural changes next.
3. Build: we design schemas, write migrations, add indexes, tune configuration and set up replication, caching or search.
4. Test: we benchmark against realistic data volumes, compare query plans before and after, and rehearse restores and failovers.
5. Launch: changes go live in controlled steps, with online index builds and monitoring during and after each change.
6. Support: we can monitor, patch and tune the database over time, and help your team as data and traffic grow.

Why CodeWiz

• Full-stack perspective: we build the Laravel, Node.js and WordPress applications that sit on top of databases, so we fix problems in the queries and the code, not just in the server.
• The right tool for each job: PostgreSQL, MySQL, MongoDB, Typesense and Redis are all part of our daily work, so we recommend what fits rather than what we happen to know.
• Open-source first: no licence fees and no lock-in – your data stays in standard, portable formats.
• Fair pricing: premium development without premium prices, from Banja Luka, working remotely with clients locally and internationally.
• Performance in the same hands: database tuning, caching, Varnish and Cloudflare are all things we do – read more about CodeWiz.

Frequently Asked Questions

Should I choose PostgreSQL or MySQL for a new project?

For a custom application without platform constraints, we usually recommend PostgreSQL because of its strong integrity features, JSONB and extensions. If you are building on WordPress, WooCommerce, Magento or PrestaShop, MySQL or MariaDB is the natural choice. Both are excellent when designed and tuned properly.

How much do database optimization services cost?

It depends on the size of the database, the number of applications using it and how deep the problems go. A focused audit with quick wins is a small engagement; a schema redesign with data migration or a move to replication and sharding is larger. We give you a clear estimate after the initial review.

Can you speed up my database without changing the application?

Often, yes. Indexes, configuration tuning, connection pooling and read replicas can be added without touching application code. The biggest gains, however, usually come from fixing a few inefficient queries in the code, which we can do as well.

Is it risky to optimize a production database?

It is when done carelessly. We test changes on a copy with realistic data, build indexes online (CREATE INDEX CONCURRENTLY or online DDL in MySQL), schedule heavy operations for low-traffic windows and always have a verified backup before making structural changes.

When do I need MongoDB or Typesense in addition to SQL?

Add Typesense when users need fast, typo-tolerant search or filtering across large catalogues. Consider MongoDB when your data is naturally document-shaped and varies a lot between records. If neither applies, a well-designed PostgreSQL or MySQL database is usually enough on its own.

Let’s Make Your Database Fast and Reliable

Tell us about your application, your data and where it hurts today, and we will propose a clear plan to fix it. Contact us to discuss your project, or explore our full range of database services.