Freelance SQL developer
SQL developer for reliable, high-performance databases
Behind every solid application is a well-thought-out database. SQL is the foundation you never see but that decides everything: the reliability of your data, the speed of your screens, the peace of mind of your future changes. I build it with care, on MySQL or PostgreSQL.
SQL is the silent foundation behind every application I deliver: it's what structures, organises and serves up your data. I design clean relational databases on MySQL or PostgreSQL, write readable and performant queries, and safeguard data integrity — the part you never see, but on which everything else rests.
SQL is the language that lets you talk to relational databases. And a relational database is simply the place where your application stores its information in an organised way: your customers in one table, their orders in another, the products in a third, and clean links between those tables. Rather than piling everything in one place, you break information into coherent pieces, avoid duplicates, and reassemble whatever you need on demand. It's this model, invented half a century ago and still dominant today, that powers the vast majority of serious web applications.
In practice, SQL handles four everyday things: storing data, retrieving it, modifying it and deleting it. When you display the list of your latest orders, when a filter shows only the unpaid invoices, when a customer updates their address or a closed case is archived, it's a SQL query working behind the scenes. The strength of this language is that you describe what you want to obtain — "all of this customer's orders, sorted by date" — and the database takes care of finding the most efficient path to get there. The catch is that the database has to be well built for that path to stay fast.
The heart of the relational model is joins. A join links two tables together: matching each order to its customer, each invoice line to its product, each appointment to the person handling it. It's this mechanism that lets you store each piece of information only once, in its place, without copying it everywhere. Without clean relationships, you quickly end up with a customer's name written in ten different spots that eventually contradict each other. Careful modelling, on the contrary, keeps your data consistent by design — it's what separates a database that ages well from one that becomes a headache after a year.
I never treat the database as a technical detail to sort out at the end. Quite the opposite: I start with it. A poorly thought-out schema at the outset is paid for throughout the project's life, in bugs, slowdowns and features that are impossible to add cleanly. Conversely, a few hours spent modelling well at the start save weeks later on. Clear tables, well-placed primary and foreign keys, data types suited to each field: this invisible work is the best investment in a project, because it shapes everything built on top of it.
These days, you rarely write SQL by hand all day long — and that's a good thing. On Laravel projects I use Eloquent; on Symfony, Doctrine. These are ORMs: tools that automatically translate your code into SQL queries, so you handle "Order" or "Customer" objects rather than writing queries over and over. It's faster, more readable and safer day to day. But this tool absolutely doesn't remove the need to understand what's happening underneath: a misunderstood ORM produces catastrophic SQL without anyone noticing.
The most common example is the N+1 query. You display a list of a hundred orders and, for each one, you ask for the customer's name: without precautions, the ORM runs one query for the list, then a hundred more, one per customer. A hundred and one queries where two would have done. On a demo page with ten rows, no one notices a thing. In production, with thousands of records, the page collapses. Spotting and fixing these N+1 queries — through eager loading of relationships — is one of the reflexes I apply systematically, because it's one of the most frequent causes of slowness in web applications.
Understanding SQL also means knowing when the ORM reaches its limits and taking back control. For a dashboard with complex aggregations, a report that crosses several tables, or a migration query over millions of rows, a hand-written SQL query is often clearer and considerably faster than the generated equivalent. I don't hesitate to drop down to raw SQL when it's warranted, while keeping the application protected: parameterised queries, never string concatenation, to close the door on SQL injection. The ORM for convenience, raw SQL for precision — and knowledge of both to choose wisely.
This dual command of the tools changes the quality of the final result. Many developers stop at the ORM and are at its mercy: they don't know why a page is slow, nor how to make it fast. Because I read the generated SQL, I can place the right indexes, rewrite a relationship, adjust a query, and turn a sluggish page into an instant one — without changing anything the user sees. That's exactly the kind of difference you feel in use, especially when the volume of data grows over time and what worked at launch starts to struggle.
When an application becomes slow, the database is very often the cause — and the first thing I look at is the indexes. An index is the equivalent of the index at the back of a book: without it, to find a specific row, the database has to read the entire table from start to finish; with it, it goes straight to the point. A database without indexes on the right columns can be a thousand times slower than it should be, without anything appearing to be "broken". Conversely, adding indexes blindly slows down writes and bloats the database for nothing. The whole art is to place just enough of them, in the right spots.
To decide, I don't guess: I analyse. The EXPLAIN command shows exactly how the database executes a query — which tables it scans, which indexes it uses or ignores, how many rows it examines. It's this tool that turns optimisation into methodical work rather than a gamble. I identify the slow queries, I understand why they're slow, I add the missing index or rewrite the query, then I verify the gain. Very often, on an existing database handed to me "because it's sluggish", two or three well-chosen indexes are enough to cut response times tenfold, without touching the rest of the application.
Performance is worthless if the data is wrong, and that's where integrity comes in. A well-designed database protects itself: foreign keys prevent an order tied to a customer who doesn't exist, unique constraints block duplicates, NOT NULL constraints guarantee a required field is never left empty. And for sensitive operations — a payment, a transfer, an order touching several tables at once — I use transactions: either everything succeeds, or nothing happens, never an inconsistent in-between state. These safeguards, set at the database level, are worth more than any check added in the code, because they protect the data whatever happens above.
Finally, a database holds what your business has that's most precious, and it should be treated as such. Before any work on real data, I make a backup — you never work without a safety net. I set up a regular backup strategy and version every schema change through migrations, so it's always clear who changed what and you can roll back cleanly. Losing data or corrupting a database through a careless action is not an option: rigour on this point is part of the work, even when it doesn't show.
I'm a freelance developer based in Martinique, and the database is rarely a standalone service: it comes with the application I build, in Laravel or Symfony. That's precisely the value of having a single point of contact across the whole chain. The developer who designs your screens is also the one who models your data: the two are thought through together, consistent by design, rather than glued together after the fact. You don't have to bridge the gap between a "front-end guy" and a "database guy" who don't talk to each other.
For a business in Martinique, that means a point of contact on the ground, in your time zone, who understands your environment. Usage is overwhelmingly mobile and connections aren't always ideal: a well-optimised database, here, isn't an engineer's luxury, it's what makes a page load fast on a phone over a temperamental network instead of keeping your customer waiting. A heavy query you don't even feel on an office fibre connection can ruin the experience in the field — and I design with that in mind from the start, not by discovering it after going live.
In practice, whether it's a brand-new project or an existing database, my way of working stays the same: transparency and caution. For a new project, I model it with you, document the schema, and explain my choices without needless jargon. For a legacy database handed to me, I audit what exists, spot what's wrong, and propose improvements in stages, without breaking everything and without putting your business on pause. Versioned migrations, a backup before every change, previews you can test: you keep control and visibility at every step.
Finally, I don't leave you with a black box only you would understand. The schema is documented, the migrations tell the database's story, and another developer can pick up the work without rediscovering everything. I offer ongoing support for changes and maintenance, and 30 days of support are included after going live. A database is meant to last for years and grow with your business; my role is to deliver one that's healthy today and stays that way tomorrow, without technical debt quietly piling up beneath the application.
The advantages
- Reliable foundation: clean relational modelling, set from the start, that confidently carries the whole application above it.
- Performance under control: analysis of slow queries with EXPLAIN, targeted indexes, N+1 queries hunted down and fixed.
- Integrity by design: foreign keys, unique constraints and transactions guarantee consistent data, with no duplicates or orphans.
- ORM and SQL mastered: Eloquent and Doctrine for convenience, raw SQL when precision demands it, and the judgement to choose.
- Data security: parameterised queries against SQL injection, a backup before any work, never any work without a safety net.
- Taking over the existing: auditing a legacy database, fixing inconsistencies and improving in stages, without rewriting everything.
Limitations to be aware of
- It's not an end in itself: SQL is the foundation of an application, not a standalone deliverable. It comes into its own with the Laravel or Symfony project it powers.
- Relational isn't always the right choice: for massively unstructured data or very high-throughput caching, a NoSQL database may be a better fit.
- Good modelling requires scoping: you need to understand your business before designing the tables, which means a real conversation up front.
- Optimisation has its limits: beyond a certain volume, no index replaces an architecture overhaul — better to anticipate than to patch indefinitely.
SQL and relational databases cover the vast majority of web needs, but they aren't always the only option. Here's how I decide based on your project, without imposing a technology for its own sake.
Choose SQL if…
- Your data is structured and linked together: customers, orders, products, invoices.
- You want strong integrity: no duplicates, no orphaned data, rules guaranteed by the database.
- Your application is built on Laravel or Symfony, where MySQL and PostgreSQL are the natural, proven option.
- You need analytical queries, reports or cross-references between several tables.
- You're planning for the long term: relational is mature, hostable anywhere and easy to take over.
Prefer something else if…
- Your data is massively unstructured or highly changeable: a document database may be more flexible.
- You need ultra-fast caching or volatile sessions: Redis is a better fit than SQL.
- Your volume is colossal with extreme write loads: some distributed databases scale better.
- You mostly store files or media: the file system or object storage remains more appropriate.
- The need is trivial and throwaway: a simple file may suffice without setting up a full database.
- Database modelling for a business application
- Query and performance optimisation on an existing database
- Migration and clean-up of legacy data
- Reporting and analytical queries on your data
The foundation of every application
No Laravel or Symfony application holds up without a healthy database. Clean modelling from the outset spares you months of patching later on.
Performance under control
Well-placed indexes, readable queries, efficient joins: a database that responds fast even as the volume of data grows.
Data integrity
Foreign keys, constraints and transactions: your data stays consistent, with no duplicates or orphans rotting the application from within.
Modelling
Relational schema, tables, primary and foreign keys, well-suited types. Just the right amount of normalisation, neither too much nor too little.
Migrations and constraints
Versioned migrations (Laravel/Symfony), integrity constraints, default values, indexes designed in from the start.
Queries and data access
Queries through Eloquent or Doctrine, raw SQL where it makes sense, prevention of injections and N+1 queries.
Optimisation and monitoring
Analysis of slow queries (EXPLAIN), targeted indexes, backup and maintenance strategy.
Client projectBonnes Affaires Immo
A real estate website in Martinique with clear listings, professional photography and immersive drone video.
Client projectMen'Immo
Custom-built Symfony real estate platform with a multi-criteria search engine and a filterable property catalog in Martinique.
Client projectElianza Conseil
Symfony showcase site for an organizational performance consulting firm, with service-specific conditional appointment booking.
FAQ
Related expertise
Related services
Read on the blog
Build a Website in Guadeloupe
Choose the right website, scope the project remotely and build useful local visibility in Guadeloupe without creating artificial location pages.
July 1, 2025
Build a Website in Martinique
From choosing the format to post-launch support: a practical method for building a useful, measurable website for your activity in Martinique.
June 30, 2025
Website: Definition, Purpose and Steps to Create Your Own
A website has become an essential tool today, whether you are a business, an association or an individual. At…
June 29, 2025A SQL project? Let’s talk.
I scope out your needs and tell you honestly whether SQL is the right choice for your project.