How do I mock MariaDB queries in tests?

Record your application once against a real MariaDB with Keploy. It captures each query, its parameters, and the result set the server returned at the protocol level, then answers the same queries from that recording.

Is Keploy a Testcontainers MariaDB alternative?

For replay, yes. Testcontainers boots a real MariaDB in every CI job and needs a Docker runtime; Keploy records that server once and replays its responses with neither. Keep Testcontainers for unrecorded queries.

Can I record against MySQL and replay against MariaDB?

You should not. The dialects have diverged on RETURNING, sequences, and JSON handling, and Keploy records the server banner with the exchange so the two are distinguishable. Record against the server you deploy.

Does Keploy support MariaDB's RETURNING clause?

Yes. RETURNING is part of the query and its result set is part of the response, so the whole exchange is recorded and replayed exactly as the server produced it.

Does Keploy work with Galera cluster setups?

Recording works against any node, since capture is at the client-server protocol. Cluster-level behaviour such as conflict resolution is not simulated on replay — the recorded responses are whatever that node returned.

Is Keploy free to use with MariaDB?

Yes. The Keploy CLI is open source under Apache 2.0 and free to run on any service with no seat limits. Nothing is installed into MariaDB and no plugin is required.

Keploy as a MariaDB testing framework

Keploy mocks MariaDB by recording its wire protocol beneath your driver, capturing the exact result sets your queries returned, then replaying them during tests. No MariaDB instance runs in CI, no schema is created, and no seed script is involved.

Generate MariaDB tests free

keploy record -c "java -jar orders.jar"

18.4K+

1.2M+300M+mocks createdSlack

What Keploy gives a MariaDB team

Captured at the MariaDB wire protocol

MariaDB speaks a MySQL-compatible protocol with its own extensions. Keploy records beneath the driver, so what replays is the bytes the server sent — including MariaDB-specific capability flags.

Below MariaDB Connector/J, mysql2, PyMySQL
Column types from the server's metadata
Prepared statements and parameters
Transactions replay in order

Try Keploy for free Explore the docs

The problem

Why MariaDB integration tests slow teams down

The friction is rarely the assertions. It is everything around them — spinning up dependencies, keeping mocks honest, and repairing tests after every refactor.

Book a call Explore the docs

Three ways to do it

Testing MariaDB: by hand, with Testcontainers MariaDB, or with Keploy

Testcontainers gives real MariaDB semantics and charges a container per job. Keploy records that server once and replays its responses with no runtime at all.

By hand

Testcontainers MariaDB

With Keploy

Select any row for the full comparison, with code.

Get started Book a call

Same coverage, three costs

What you write for MariaDB vs what Keploy records

All three produce the same assertion. Only the third still passes after the next refactor without anyone editing it.

By hand2–4 hours

OrderRepositoryStub.java

hand-written

// Hand-written stub: no SQL is executed or validated.

package com.acme.orders;

import java.util.*;

class OrderRepositoryStub implements OrderRepository {

private final Map<String, Order> rows = new HashMap<>(

Map.of("ord_1", new Order("ord_1", 4200, "NEW")));

@Override

public Optional<Order> findById(String id) {

return Optional.ofNullable(rows.get(id));

}

@Override

public Order insertReturning(Order order) {

// MariaDB's RETURNING clause is never exercised here.

rows.put(order.id(), order);

return order;

}

MariaDB's RETURNING clause, its sequences, and its JSON functions are all invisible to this stub, so a dialect bug reaches production.

Testcontainers MariaDB1–2 hours

OrderRepositoryIT.java

tool-assisted

// Testcontainers MariaDB: a real server, Docker in CI.

package com.acme.orders;

import org.junit.jupiter.api.*;

import org.testcontainers.containers.MariaDBContainer;

class OrderRepositoryIT {

static MariaDBContainer<?> db =

new MariaDBContainer<>("mariadb:11").withInitScript("schema.sql");

@BeforeAll static void boot() { db.start(); }

@AfterAll static void stop() { db.stop(); }

@Test

void findsASeededOrder() {

var repo = new JdbcOrderRepository(dataSource(db));

var order = repo.findById("ord_1").orElseThrow();

assertEquals(4200, order.amountMinor());

}

Real dialect semantics — and every CI job touching this class pulls an image, boots a server, and runs the init script first.

With Keploy~5 minutes

mocks.yaml

auto-generated

# Recorded with: keploy record -c 'java -jar orders.jar'

# The MariaDB response, captured at the protocol level.

version: api.keploy.io/v1beta1

kind: MySQL

name: mock-2

spec:

metadata:

server: "MariaDB 11.4"

operation: query

request:

query: "SELECT id, amount_minor, state FROM orders WHERE id = ?"

params:

- "ord_1"

response:

columns:

- name: id

type: VAR_STRING

- name: amount_minor

type: LONG

- name: state

type: VAR_STRING

rows:

- id: "ord_1"

amount_minor: 4200

state: "NEW"

The server banner is recorded with the exchange, so a recording made against MariaDB cannot be mistaken for one made against MySQL.

Times are estimates for authoring one endpoint’s coverage from scratch, not measurements.

Explore the docs Request a trial

Keploy vs the alternatives

MariaDB testing tools, compared

The options a team on relational databases actually reaches for, and where each one genuinely wins. Select a row for the full comparison.

Keploy

Testcontainers

H2

DBUnit

pg-mem

Postman

SmartBear ReadyAPI

Best in classStrongPartialNot covered

Assessments reflect each tool’s documented behaviour, not benchmark measurements.

Request a trial Book a call

How it works

Record your MariaDB app once, replay it forever

Keploy sits below your MariaDB process at the network layer. It watches the calls your app already makes, then serves them back on replay so tests run with no dependencies attached.

Your MariaDB appGET/api/v1/orders/{id}200

RecordingKeploy proxyeBPF · userspace

JavaMariaDB Connector/J and Spring Data JPA

Node.jsmariadb, mysql2, and Prisma

Pythonmariadb, PyMySQL, and SQLAlchemy

Gogo-sql-driver/mysql and GORM

+2 more MariaDB clients

An example shape of a captured call. Your own endpoints and dependencies come from your real traffic, so nothing here has to be written by hand.

Try Keploy for free Request a trial

Mock coverage

MariaDB clients Keploy records, driver by driver

Keploy captures MariaDB at the wire protocol, so 5 of these 6 clients need no adapter, no test double, and no MariaDB instance in CI.

Explore the docs Book a call

Quick start

Your first MariaDB test suite in under five minutes

Every command below runs against your existing MariaDB service. Nothing in your source tree changes.

1
1Install the Keploy CLI
A single binary. It needs a Linux kernel with eBPF support, or Docker on macOS and Windows — and it adds nothing to your project's dependencies.
curl -sSL https://keploy.io/install.sh | bash
2
2Record your service
Pass the command you already use to start the app. Keploy runs it and watches every socket it opens.
keploy record -c "java -jar orders.jar"
3
3Exercise the paths you care about
Run the app with your development MariaDB reachable. Every query and every result set the server returns is captured together.
curl localhost:8080/orders/ord_1
curl -X POST localhost:8080/orders/ord_1/confirm -d '{"paymentToken":"tok_123"}'
4
4Replay in CI
Replay serves the recorded dependency responses, so the job needs no service containers and no Docker daemon.
keploy test -c "java -jar orders.jar" --delay 15