MySQL
MySQL runs an enormous number of web applications and internal tools, many of which have long outlived the people who built them.
MySQL runs an enormous number of web applications and internal tools, many of which have long outlived the people who built them.
What MySQL holds, and why that matters here
MySQL is ubiquitous in web applications, internal tools and systems assembled over time. A common situation is a working system whose original developers have moved on, whose interface covers only part of what the data supports, and whose remaining questions require direct access.
For those organisations, a conversational read layer answers questions the application was never built to answer.
- Application data — whatever the system records.
- User and customer records — where the application holds them.
- Transactional history — events and states over time.
- Reference tables — lookups the application depends on.
- Views — any curated access already defined.
Questions Elbi can answer from a MySQL database
What is this record?
A specific item retrieved and described.
How many match this?
A count without technical involvement.
What changed and when?
History against a record.
Which are still open?
A filtered set summarised for a business reader.
What was the total?
A period figure.
Is this in the system?
Existence and state.
How Elbi queries MySQL without touching production
- An account tied to a hostMySQL accounts are defined as a user at a host, so the assistant's account can be created to accept connections only from the address the connection uses. It has its own password or certificate, and REQUIRE SSL can insist that every session is encrypted.
- SELECT on views, and nothing elseThe account is granted SELECT on a handful of named views and holds no global privileges. Because a MySQL view runs with its definer's rights by default, the account can read through a view without any access to the tables underneath it.
- Pointed at a replica, not the primaryWhere you run replication, the connection reads from a replica with read_only set, so a slow lookup never competes with the application for the primary. MariaDB replicas behave the same way for this purpose.
- Fixed, parameterised statementsEach supported question is a prepared statement written during deployment, with placeholders for the reference or date the person gives. The assistant supplies values; it does not compose SQL, so no wording of a question can produce an unplanned query.
- Limits on time and volumeA statement time limit (max_execution_time in MySQL, max_statement_time in MariaDB) and per-account resource limits stop a misbehaving lookup from running on. Someone asking about one order never needs more than a few rows.
- Rows become sentencesStatus codes, flags and foreign keys are turned into plain Arabic or English, and the view is where awkward storage choices — dates held as text, soft-deleted rows still present — are straightened out so nothing has to be guessed.
Grants, hosts and what stays yours
| Direction of access | Read-only, and it should stay that way. SELECT on named views is the whole grant; writes belong in the application that owns the data and enforces its rules. |
|---|---|
| Who can see what | The views define the outer limit of what the account can read. Which of those answers a person receives follows their identity from your own sign-in, so a customer is only ever answered about their own records. |
| Credentials | A dedicated account at a fixed host, with a password or certificate you set. ALTER USER rotates it and DROP USER removes it, both from your side and without involving us. |
| Where data goes | Rows returned by a lookup are used for the reply they were fetched for. Message content is destroyed within 24 hours, most often when the conversation ends, and nothing is sent to an external AI service. |
| Audit | The general query log records everything and is heavy for production use; the MariaDB audit plugin or MySQL Enterprise Audit can record a single account's activity instead, on your server. |
| If it is unavailable | If the database cannot be reached or refuses the account, the assistant says so and offers a person. It does not fall back to an earlier answer or a guess. |
What the MySQL connection replaces
The characteristic MySQL situation is a system that works but cannot be extended cheaply. Adding a new screen means development effort against a codebase nobody wants to touch; adding a conversational read layer means defining a handful of named lookups.
That makes it a practical route to value for older internal systems that are otherwise stuck — the data becomes reachable without a development project.
The same discipline applies as with any database: curated, named lookups defined by people who understand the schema, exposed to people who do not.
Who gets the most from a MySQL connection
Web applications
Data the front end was never built to surface.
Internal tools
Systems whose developers have moved on.
SMEs
Operational data with no reporting layer at all.
Any legacy system
Reaching data without a development project.
Getting value from an older MySQL application
The typical MySQL situation is a working application whose screens cover only part of what its data can answer. Start by listing the questions staff currently take to whoever still understands the schema, often a developer or an outside vendor, and count how often each comes up. The most frequent few become the first views.
Replica lag matters for time-sensitive answers. A replica normally follows closely behind the primary but can fall behind under load, and MySQL reports that lag on the replica itself. For "has my payment gone through?" it is worth checking before answering; for last month's totals it makes no difference.
Arabic text needs a look before launch. Older applications sometimes stored Arabic in columns declared with a Western European character set, which reads back as garbled characters until the encoding is dealt with. Finding that in testing is far cheaper than a customer finding it.
What connecting MySQL or MariaDB involves
- Pick the questions and the key behind eachFor every question, identify the tables involved and the key a person will supply — an order number, an account reference, an email address — and check that the key column is indexed. A question without a reliable key is not ready yet.
- Write the viewsCreate a view per question, or per small group of questions, exposing only the columns the answer needs. Keep them in a separate database or clearly named, so they are easy to review and hard to confuse with application objects.
- Create the account and grant SELECTCREATE USER at the connecting host, GRANT SELECT on those views alone, require TLS and set resource limits. SHOW GRANTS for the account should fit comfortably on one screen.
- Point it at a replicaIf a replica exists, use it. If not, decide whether the lookups are light enough for the primary, or whether this is the moment to add one.
- Test with awkward inputsUnknown references, a reference that belongs to someone else, Arabic names spelt several ways, and a request that would return far too many rows. Each should end in a clear answer or a person.
- Go live on a few viewsLaunch with a handful of views and add more as real questions show where the gaps are, reviewing each new view as carefully as the first.
Personal data in MySQL application tables
Application databases usually hold personal data in the same tables as everything else: names, phone numbers and national ID numbers sit next to order lines. Under the Saudi Personal Data Protection Law the view is the natural place to minimise, because columns a question does not use can be left out of it entirely.
Residency is decided by where the database runs — your own server, a hosting provider, or a managed cloud service in a region you chose — and the connection does not change that. Record it with the list of views so a reviewer sees where the data is and exactly which columns can be read.
The grant list is the short answer to "what can it see?". Keeping it short enough to read aloud is a governance measure in its own right.
What organisations typically see
How MySQL data is usually reached, and the trade-offs
The most common route is a database admin tool such as phpMyAdmin or Adminer, handed to the few people who can use it. It can answer anything, which is the problem: the access is broad and the answer depends on whoever is at the keyboard.
BI tools connected to a replica serve recurring reports well, and many MySQL shops already run one. They suit people who want a dashboard, and are less suited to a customer asking about a single order in Arabic outside office hours.
Some teams put a small internal API in front of the database for each new question. That is the most controlled option and also the slowest, because every question becomes a development task.
The recurring mistake is an account with SELECT on the whole schema, or the application's own credentials reused because they were to hand. Either one turns a narrow lookup into a copy of the application's full access.
Common questions about the MySQL connection
No, but you need someone who understands the schema to define the lookups. That is usually a short exercise.
No. Read-only by default and by recommendation.
Common. Mapping it is part of deployment, and the output is documentation you did not previously have.
Yes. MariaDB began as a fork of MySQL and behaves the same way for everything described here: accounts, grants, views and replicas. Where a setting has a different name, such as the statement time limit, the MariaDB one is used.
No. It runs prepared, parameterised statements written against named views during deployment. There is no route by which a question turns into free-form SQL against your database.
Reading from a replica keeps it off the primary altogether. Where there is no replica, each lookup is a narrow, time-limited query on an indexed key, which is a very different load from a report.
Connect it to your own systems
A working assistant against your own records, in both languages.