Tested on real databases.
Every value checked.
Sample data in a demo proves little. So SQLAtlas converted eight public sample databases, the ones database people learn on, between five database servers. After every run, a separate check compared every value of every row with the source.
- 46 of 46conversion runs matched, value by value
- 48.8 Mrows written and checked, none sampled
- 0rows rejected
- 11bugs found and fixed before release, each with a test
The conversions
Each database went to MySQL 8.0 and 8.4, MariaDB 10.11 and 11.4, and PostgreSQL 16, except its own server.
| Database | From | Runs | Rows | Result |
|---|---|---|---|---|
| pubs | SQL Server 2022 | 5 | 255 | 5 matched |
| Northwind | SQL Server 2022 | 5 | 3,308 | 5 matched |
| Chinook | SQL Server 2022 | 5 | 15,607 | 5 matched |
| Chinook | MySQL 8.4 | 4 | 15,607 | 4 matched |
| Chinook | PostgreSQL 16 | 4 | 15,607 | 4 matched |
| AdventureWorks2022 | SQL Server 2022 | 5 | 760,837 | 5 matched |
| AdventureWorksDW2022 | SQL Server 2022 | 5 | 1,060,820 | 5 matched |
| WideWorldImporters | SQL Server 2022 | 5 | 4,713,833 | 5 matched |
| employees | MySQL 8.4 | 4 | 3,919,015 | 4 matched |
| Pagila | PostgreSQL 16 | 4 | 62,322 | 4 matched |
The largest, WideWorldImporters with 4.7 million rows, took 4.8 to 6.4 minutes per target. Speeds were 3,450 to 16,346 rows per second on databases over 100,000 rows, with every server on one machine.
How each run was checked
SQLAtlas verifies every conversion itself, and that passed in all 46 runs. It was not taken on trust. A separate check read both databases directly:
- Every row: the row count of every table, then every value of every column, as exact text from its own server. Decimals as exact digits, floating-point values bit for bit, dates and times as text.
- The structure: primary keys, unique keys, foreign keys, indexes, CHECK constraints and defaults.
- No excuses: any difference counts as a failure, unless SQLAtlas announced it in the plan and you accepted it.
Where a value cannot be kept exactly, SQLAtlas asks first. A SQL Server datetime2(7) has a seventh fraction digit that MySQL, MariaDB and PostgreSQL cannot store, so SQLAtlas offers to keep the exact original as text beside it. That question came up 450 times in these runs.
The tests found eleven conversion bugs. One was critical: MySQL FLOAT values read with six significant digits. All were fixed before the final run, and each has its own regression test.
Would a DBA use it?
SQLAtlas isn't built for database administrators. But if a DBA would trust it, everyone else can too. So the things a DBA relies on were measured on eight servers: SQL Server 2022, PostgreSQL 13, 16 and 17, MySQL 8.0 and 8.4, and MariaDB 10.11 and 11.4.
| Check | Result |
|---|---|
| Wrong password, bad certificate, wrong SSH host key | Refused on every server, with a plain reason. Never a silent fallback |
| SSH host key missing or wrong | Refused before any password or key is sent |
| Stop a long query | Takes effect within 5 ms |
| A schema of 5,000 tables | Listed in a quarter of a second |
| Last page of a 3.65 million-row table | 2.2 s |
| A session waiting on a lock | Shown in the activity view on all four engines |
| Export 3.65 million rows to CSV | 15 s, using about 11 MB of memory |
What isn't there yet
Honest limits, listed for later releases:
- SQL Server
PRINTandRAISERRORmessages are not shown yet. - Stopping a query on SQL Server restarts the session, so an open transaction is lost. SQLAtlas says so when it happens.
- Views, procedures, functions and triggers are exported as drafts for you to review, not converted automatically.
- Not tested: Oracle (SQLAtlas has no Oracle connection), databases above about 4.7 million rows, and remote networks.
Azure SQL support is built in and tested against a local SQL Server set up like Azure (certificate-verified TLS, contained users). A run against a live Azure SQL instance is on the pre-launch checklist.