Windows-native · pure xcopy deployment · no Docker · six database dialects on one server

Your T-SQLOracleFirebirdPostgresSQLiteMySQL app now has full CRUD on MySQLT-SQLPostgresFirebirdOracleT-SQL data.

Tables · views · functions · stored procedures

One SQL connection to rule them all.

EQLServer is a Windows-only, xcopy-deployable database server that speaks T-SQL, PostgreSQL, MySQL and MariaDB, Oracle, SQLite, Firebird and InterBase on the same tables, views, functions and stored procedures. No Docker, no WSL, no Linux VM, no installer: a folder of native Windows binaries for x64, with ARM64 in the works. Every dialect can insert, select, update and delete the same rows and call the same functions and procedures, with full ACID guarantees and no connector in between. One instance holds as many databases as you need. Unzip. Start. Point your apps at it.

Buy a license · $250 Book a POC · $1,000

eqlserver.zip · a few hundred MB pure xcopy deployment · no installer · no initdb no Docker · no WSL · no VM multi-database: unlimited databases per instance no limit on cores, RAM or database size Windows only: 10/11 and Server 2019+ on x64 · Windows 11 on ARM64 (experimental)

sqlcmd — eqlserver:1433 (TDS)

-- T-SQL session. wp.* is your own WordPress (MySQL),
-- dbo.* is your own schema. One transaction, both ways.
BEGIN TRAN;
UPDATE wp.wp_posts SET post_status = 'publish'
WHERE  ID = 4711;
INSERT INTO dbo.Orders (CustomerId, Total, Source)
SELECT c.Id, 129.00, 'woocommerce'
FROM   wp.wp_users u JOIN dbo.Customers c ON c.Email = u.user_email
WHERE  u.ID = 17;
DELETE FROM wp.wp_postmeta WHERE meta_key = '_stale_cache';
COMMIT;
GO

statement	target dialect	result
UPDATE wp.wp_posts	MySQL table	1 row affected
INSERT INTO dbo.Orders	T-SQL table	1 row affected
DELETE FROM wp.wp_postmeta	MySQL table	42 rows affected

COMMIT · 6 ms · one ACID transaction · no linked server · no ETL

T-SQL · TDS :1433PostgreSQL · libpq :5432MySQL · MariaDB · :3306Oracle mode · orafceSQLite · drop-in sqlite3.dllFirebird · InterBase · :3050pgvector · pg_trgm · PL/Python built in · PostGIS moduleWindows-native · pure xcopy deploymentnative ARM64 buildno Docker · no WSL · no VMACID across dialectsHTTPS tunnel · port 443 · no VPNbuilt-in monitoring T-SQL · TDS :1433PostgreSQL · libpq :5432MySQL · MariaDB · :3306Oracle mode · orafceSQLite · drop-in sqlite3.dllFirebird · InterBase · :3050pgvector · pg_trgm · PL/Python built in · PostGIS moduleWindows-native · pure xcopy deploymentnative ARM64 buildno Docker · no WSL · no VMACID across dialectsHTTPS tunnel · port 443 · no VPNbuilt-in monitoring

How it works

EQLServer unites PostgreSQL, MS SQL Server, MySQL, Oracle, SQLite and Firebird in a single server that understands every dialect – including xcopy deployment and the tunnel.

EQLServer combines Babelfish and orafce with its own MySQL, Oracle, SQLite and Firebird layers on one current PostgreSQL core, and packages the whole thing as a portable Windows build. Every dialect maps onto the same catalog, so there is nothing to synchronise.

Fig. 3 — Request path, from driver to disk

APPLICATION

ADO · FireDAC · JDBC

Npgsql · psycopg

mysqli · PDO · JDBC

PG driver · Oracle mode

sqlite3.dll (ours)

fbclient · FireDAC · IBX

PROTOCOL

TDS :1433

libpq :5432

MySQL :3306

libpq :5432

in-process → libpq

Firebird :3050

DIALECT

Babelfish

native

EQLServer MySQL layer

orafce · EQLServer Oracle layer

SQLite API shim

EQLServer Firebird layer

STORAGE

PostgreSQL core · unlimited databases per instance · shared catalog · pgvector · one data directory inside eqlserver.zip

Built on PostgreSQL, Babelfish for PostgreSQL and orafce (permissive open-source licenses; every license text ships in the package). The MySQL, Oracle-mode, SQLite and Firebird layers, the Windows port, the portable packaging and the support are EQLServer.

Your query tools keep working, too.

Each listener speaks the real wire protocol, so the tools your team already has connect as if nothing changed.

T-SQL · port 1433

SQL Server Management Studio (SSMS), Azure Data Studio, sqlcmd, bcp, LINQPad

PostgreSQL · port 5432

pgAdmin, psql, DBeaver, DataGrip, TablePlus, Beekeeper Studio

MySQL · port 3306

MySQL Workbench, HeidiSQL, phpMyAdmin, mysql CLI, Navicat

Oracle mode

Any PostgreSQL client: DBeaver, DataGrip, pgAdmin, psql

SQLite · DLL swap

sqlite3 shell, DB Browser for SQLite, any tool that loads sqlite3.dll

Firebird · port 3050

IBExpert, FlameRobin, isql, FireDAC and IBX design time, DBeaver

Multi-database

Many databases, one instance. Every dialect in each of them.

One database per client company, one per fiscal year, an archive, a test database next to production, several hosted customers: one EQLServer instance holds as many databases as you need. Software built around separate client databases moves over as it is.

Unlimited databases per instance
Cross-database queries, as in SQL Server
All six dialects in every database
Backup and restore per database
Monitoring and Sentinel per database
One license per computer, no per-database fee

-- T-SQL: master data joined with one client
SELECT i.ItemNo, i.Name, SUM(l.Qty) AS Sold
FROM   Stock.dbo.Items i
JOIN   Client1.dbo.InvoiceLines l
       ON l.ItemNo = i.ItemNo
GROUP BY i.ItemNo, i.Name;

-- the same databases from other dialects
USE Client2;                -- MySQL
localhost:Client2         -- Firebird
sqlite3_open("Client2.db") -- SQLite DLL

Installation effort

30 seconds. No admin rights. Any folder. No container.

The license is the smaller saving. The bigger one is every hour your support team does not spend walking a customer through a database installer, a service account and a reboot.

SQL Server Standard

setup.exe

45–90 mintypical first install, per server

Rights: Local administrator required
Location: Fixed install path, registry, service account, instance name
Prereqs: .NET, VC++ runtime, pending-reboot check, firewall rules
Reboot: Often required
Move it: Backup, reinstall elsewhere, restore, re-license

Oracle Database

OUI / runInstaller

2–4 htypical first install, per server

Rights: Administrator plus dedicated Oracle home user
Location: ORACLE_HOME, ORACLE_BASE, inventory, listener, tnsnames
Prereqs: Prerequisite checks, environment variables, DBCA database creation
Reboot: Sometimes required
Move it: Data Pump export, reinstall, import, re-license

EQLServer

eqlserver.zip

30 secunzip to first query

Rights: None. A normal user account is enough
Location: Any folder: C:\, D:\apps, a network share, a USB stick
Prereqs: None. Runtime ships inside the ZIP
Reboot: Not required after installation
Move it: Stop, move the folder, start. Done

Durations are typical values for a first, unattended-free install by an experienced administrator, excluding download time. Your own numbers will vary, but not in a direction that helps the installers.

Why "Windows-native, no Docker" is the whole point

It runs where your customers are

Mittelstand, workshops, practices, plants: Windows PCs and Windows servers, often without IT staff. Docker Desktop needs a license for companies, admin rights, Hyper-V or WSL, and someone who knows what a container is. A ZIP needs a double-click.

Native from the ground up

PostgreSQL runs natively on Windows, and so does EQLServer, with six dialects in one native Windows process instead of one server per database. No WSL, no VM, no container image underneath: Windows Event Log, Windows backups, native services if you want them.

Portable means portable

Copy the folder to a USB stick and it runs on the next machine. Put it on a network share. Ship it inside your own setup.exe, or inside no installer at all. Uninstall by deleting the folder. Nothing is left behind in the registry or the system directories.

ARM64 · experimental · part of the beta

ARM64 is on its way. Most of the databases it replaces stay x64 only.

A native Windows 11 ARM64 build of EQLServer is in the works as part of the beta, planned for launch in 03/2027: same ZIP layout, same dialects, same extensions, for Snapdragon notebooks, ARM workstations and Windows 11 ARM64 VMs in the cloud. Because EQLServer is built on PostgreSQL, it depends on a native Windows ARM64 build of PostgreSQL itself, which PostgreSQL does not offer officially; we build it ourselves. The client side is independent of that: the SQLite and tunnel DLLs come in x86, x64 and ARM64, so they match whatever architecture your application is built for.

Windows ARM64 build status · source: vendor download and platform pages, October 2026

Database	Windows ARM64	Status
EQLServer	experimental*	In the works as part of the beta: native ARM64 build with all six dialects, every extension and the same xcopy package, planned for launch 03/2027. Client DLLs already ship in ARM64.
Microsoft SQL Server	x64 only	Not supported on Windows on ARM.
PostgreSQL	x64 only	No official native Windows ARM64 build.
MySQL	x64 only	Supported Windows platforms are x86_64 only.
MariaDB	x64 only	Build support exists, but official Windows downloads are x86_64 only.
Oracle Database	x64 only	Windows x64 only; ARM64 is offered on Linux.
SQLite	native	Official ARM64 DLL and command-line tools.
Firebird	x64 only	Windows packages for x86 and x64 only.
InterBase	x64 only	Intel x86-64 only.

* Experimental: EQLServer's Windows ARM64 build is in the works as part of the beta and is planned for launch 03/2027. PostgreSQL, on which EQLServer is built, offers no official native Windows ARM64 build. Windows Server is not available natively for ARM; the target is Windows 11 ARM64.

On Windows on ARM, x64 database servers can at best run under emulation, which their vendors do not support for production. EQLServer aims to replace them with one native ARM64 server that speaks all of their dialects.

Included extensions

Maps and meaning on the same tables. No extra license.

pgvector, pg_trgm, PL/Python and PL/JavaScript ship inside the ZIP and are enabled on first start. PostGIS comes as a free, optional GIS module: one folder copied next to the server, under its own open-source license. All of them work on the same tables your T-SQL, MySQL or Oracle code already uses.

PostGIS · OPTIONAL GIS MODULE

Turns the database into a geographic information system. Coordinates, routes, areas and distances become native column types with their own indexes, so "which customers are within 25 km of this technician" is one indexed query instead of a loop over every address.

Field service and logistics: nearest technician, delivery zones, tour planning, geofences for time tracking.
Store and site data: catchment areas, overlapping territories, address validation against official boundaries.
Assets and plants: where every machine, cable, pipe or sensor sits, with distance and intersection queries.
Maps in your UI: output as GeoJSON straight to Leaflet, MapLibre or any web map.

-- customers within 25 km of a technician's position
SELECT name, ST_Distance(geo, ST_MakePoint(7.31, 50.30)::geography) AS m
FROM   customers
WHERE  ST_DWithin(geo, ST_MakePoint(7.31, 50.30)::geography, 25000)
ORDER BY m;

geometry · geographyGiST indexGeoJSONOGC standardused by OpenStreetMap

pgvector

Stores and searches embeddings, the numeric fingerprints that AI models produce for text, images or documents. Similarity becomes a SQL operator, so "find the five support tickets most like this one" or "which product description matches this photo" runs next to your business data, on your own server, with no data leaving the building.

Semantic search: find by meaning, not by keyword, across tickets, mails, manuals, product texts.
Local RAG: give an on-premises language model your own documents as context, with the vectors living beside the rows they describe.
Deduplication and matching: near-identical customers, articles or invoices without hand-written fuzzy rules.
Recommendations: similar products, similar cases, similar jobs, one ORDER BY away.

-- five tickets closest in meaning to a new one
SELECT id, subject, embedding <=> $1 AS distance
FROM   tickets
ORDER BY embedding <=> $1
LIMIT  5;

vector(n)HNSW · IVFFlat indexcosine · L2 · inner productworks with any embedding model

pg_trgm + unaccent

Splits text into overlapping three-letter pieces and indexes those. Two things follow: a search with a leading wildcard, LIKE '%meier%', finally uses an index instead of scanning the whole table, and "similar" becomes a measurable value, so Mayer, Meier and Maier find each other. unaccent strips umlauts and accents first, so Müller, Mueller and Muller match too.

Customer and article search: typo-tolerant lookups in call centers and order entry, ranked by closeness.
Faster unchanged code: your T-SQL app's existing LIKE '%…%' queries hit the trigram index through Babelfish without a single line changed.
Duplicate checks: catch "Hartmann GmbH" vs. "Hartman GmbH" on insert, without hand-written fuzzy rules.
Autocomplete: the ten closest names first, straight from the index.

-- typo-tolerant, umlaut-insensitive customer search, indexed
CREATE INDEX ON customers USING gin (unaccent(name) gin_trgm_ops);
SELECT name, similarity(unaccent(name), unaccent('Hartman Gmbh')) AS score
FROM   customers
WHERE  unaccent(name) % unaccent('Hartman Gmbh')
ORDER BY unaccent(name) <-> unaccent('Hartman Gmbh') LIMIT 10;

GIN · GiST indexsimilarity()% and <-> operatorsindexed ILIKEGerman umlauts

PL/Python

Lets you write stored procedures and triggers in Python instead of SQL. The runtime ships inside the ZIP as a portable embedded Python, so a function can parse a PDF, call a local AI model or reshape JSON, and the result lands in the table in the same transaction. Combined with pgvector it turns the database into a self-contained AI pipeline: insert a ticket, a trigger computes the embedding, the row is searchable by meaning a millisecond later.

Embeddings on insert: call Ollama or a local sentence-transformer from a trigger; vectors stay beside the rows, nothing leaves the server.
Logic that is painful in SQL: regular expressions, date parsing, Excel and PDF extraction, HTTP calls to your own APIs.
Validation and enrichment: IBAN checks, address normalisation, VAT-ID lookups as database functions any dialect can call.
Your Python packages: ship a site-packages folder with the ZIP; numpy, requests and friends are there on first start.

-- trigger: vectorise every new ticket with a local model
CREATE FUNCTION embed_ticket() RETURNS trigger AS $$
    import requests, json
    r = requests.post('http://localhost:11434/api/embeddings',
        json={'model': 'nomic-embed-text', 'prompt': TD['new']['body']})
    TD['new']['embedding'] = json.dumps(r.json()['embedding'])
    return 'MODIFY'
$$ LANGUAGE plpython3u;

plpython3uembedded Python 3, portabletriggers · functions · proceduressuperuser-defined, runs on-prem

All four are PostgreSQL-native and defined through the PostgreSQL dialect (PL/JavaScript is on board as well); the data they index or compute is the same data your other dialects read and write, and the trigram index speeds up T-SQL and MySQL queries just the same. Also on board from PostgreSQL contrib: pgcrypto, uuid-ossp, citext, hstore, ltree, pg_stat_statements. Need another extension in the package? Say so in the POC.

Remote access

Reach your server through port 443. No VPN, no installer, no firewall ticket. Or run it in the cloud.

Branch offices, home-office clients, technicians on customer sites: the EQLServer Tunnel carries your database connection inside ordinary HTTPS. The application only changes its hostname to localhost; the server exposes nothing but port 443. The gateway is built into EQLServer, so the server side needs no extra installation.

Fig. 4 — One DLL in the app, the gateway built into EQLServer

Client Your application

Connects to 127.0.0.1:21444 as before. eqlserver-tunnel.dll (32 and 64 bit, Intel/AMD and ARM64, no dependencies) runs inside the process; one call starts it. No code access? Start eqlserver-tunnel.exe next to the application instead — same logic, zero changes, works for SSMS and other third-party tools.

TDS · localhost

On the way Corporate proxy · firewall · antivirus

Sees valid TLS and a standards-compliant WebSocket, like Teams or any web app. Windows proxy settings and NTLM/Kerberos sign-on are inherited automatically; falls back to HTTP streaming where WebSockets are blocked.

HTTPS · 443

Server EQLServer Gateway

Built into the server: nothing extra to install, it starts with EQLServer. Shares port 443 with an existing IIS under its own path if needed. Forwards to EQLServer on 127.0.0.1:21444, which no longer listens externally.

built in · 443 → local 21444

Move your app to the cloud

Your Windows application, hosted, without rewriting it as a web app.

Put EQLServer on a Windows server in a data center: your own rack, a hoster, or a Windows VM at any cloud provider. Your customers keep the desktop application they know; it reaches the database through the tunnel on port 443. Nothing to install at the customer site except your app, no VPN, no database server to look after on their premises.

A cloud offer for a desktop product.

Sell hosting as a subscription next to your licenses. The code base stays the one you ship today.

One place to back up and update.

Schema changes, updates and backups happen once in the data center instead of at every customer.

Windows from end to end.

The database runs natively on Windows Server, next to whatever else your app needs there. No Linux, no containers.

Invisible to scanners

The gateway requires a per-customer access key. Without it, it answers like any web server: 404. Port scans see a website, not a database.

End-to-end encrypted

Proxies that break open HTTPS still see nothing: the TDS connection itself is TLS-encrypted inside the tunnel, so only ciphertext passes the inspection point.

Survives proxy timeouts

Proxies drop long connections after a few minutes. The tunnel reconnects within seconds and resends unacknowledged data; the application's database session stays open. Keepalive every 20 s.

One line in your code

eqlserver-tunnel.dll ships as a Windows DLL in 32 and 64 bit for Intel/AMD and ARM64. Start it from your own application once at startup; everything else stays as it is.

EQLServerTunnelStart(
  'https://db.example.com/eqlserver',
  KEY, 21444);

Or run eqlserver-tunnel.exe for tools you can't change, such as SSMS.

Three lines in the config

TunnelEnabled, certificate source (your own or automatic Let's Encrypt) and the access keys in eqlserver.config.json. The start script does the rest, idempotently.

What it can't promise

Allow-list-only proxies and captive portals that demand a browser login per connection. Running the gateway under the customer's existing domain with a valid certificate solves most of the first case.

Monitoring & operations

See every dialect at work. Back up, update and secure it without extra tools.

Monitoring is built into the server and served through the same gateway as the tunnel: open it in a browser, scrape it with Prometheus, get an e-mail when a threshold is crossed, and let the Performance Sentinel check whether your server delivers the CPU performance you pay for. Nothing to install next to EQLServer.

https://server.example.com/eqlserver/monitorexample screen

Connections by dialect

T-SQL42

MySQL31

PostgreSQL18

Firebird12

SQLite5

Oracle3

Transactions / s

1,284

Locks waiting

longest wait 0.0 s

Disk

38.2 GB

+0.4 GB this week

Last backup

03:00

verified · next 03:00

Slowest statements, last hour

SELECT … FROM dbo.Orders o JOIN wp.wp_users u …412 ms

UPDATE wp_postmeta SET meta_value = … WHERE …188 ms

EXECUTE PROCEDURE SP_REORDER_STOCK121 ms

Performance Sentinel · CPU score, last 30 days

91 % of reference · Hyper-V detected · host contention: none

Performance Sentinel

Real performance. Measurable results.

Know exactly how fast your server performs, not just how busy its CPU is. The built-in Performance Sentinel continuously measures actual processing performance with minimal overhead, compares it against reference CPU systems and flags virtualization bottlenecks.

Actual CPU performance benchmarking
Rolling history over the last 30 days
Comparison with reference CPU systems
Automatic virtualization detection
Detection of suspected host CPU contention
SQL-accessible performance diagnostics
Minimal impact on production workloads

Is your VPS delivering the CPU performance you are paying for? EQLServer tells you.

-- every result lives in an internal SQL table,
-- rolling 30 days, queryable from any dialect
SELECT day, score_pct_of_reference,
       virtualization, host_contention
FROM   eqlserver.sentinel_daily
ORDER BY day DESC;

-- example output
day         score  virtualization  host_contention
2026-10-12   71 %  Hyper-V         suspected
2026-10-11   89 %  Hyper-V         none
2026-10-10   91 %  Hyper-V         none
… 30 days

Monitoring in the browser

Connections, transactions, locks and the slowest statements per dialect, disk growth, the last backup and the Sentinel score over the last 30 days. Protected by the same access keys as the tunnel.

Prometheus and alerts

A Prometheus endpoint for Grafana, Zabbix or PRTG, and e-mail alerts when a threshold is crossed: disk, lock waits, failed backup, connection limits.

Backup built in

eqlbackup takes logical and physical backups, verifies them and restores them. Scheduled through the Windows task scheduler of a normal user account.

Updates by xcopy

Unzip the new version into a new folder and point it at your data; EQLServer upgrades the data directory. The old folder stays as your way back.

Secure by default

No default passwords: a random admin password is created on first start. Listeners bind to localhost until you open them, and every listener speaks TLS.

Offline license file

A signed license file in the folder. No activation server, no phone-home, no lockout when the internet is down.

What the proof of concept really does

We adapt EQLServer so that, ideally, you don't have to change any code.

The offer is aimed primarily at ISVs who want to ship their software together with EQLServer. A POC is not a pass/fail test of the current build. When something in your SQL does not run yet, we try to adapt the EQLServer dialect interpreter first, not your source code. The goal is minimal to zero changes in your application, and every POC leaves the product more compatible for the next one.

Run everything as it is.

You install your application on a Windows 11 VM we provide, with EQLServer already running. Your schema, your stored procedures and your application's real query log are then replayed against it. Nothing is rewritten first. Each statement gets a verdict: runs, runs with a semantic difference, or fails.

Try the interpreter first, not your codebase.

Statements that fail because a function, syntax form or type behaviour is missing are first attempted in the EQLServer dialect layer during the POC. Where that succeeds, your source stays untouched and the fix ships in the next build to every customer. Where it does not, the report gives a concrete proposal for each statement: what to change in your code to make it run, with the rewritten SQL.

Ignore what only mattered to the old engine.

Plenty of SQL exists only to tune or manage a specific server, and has no meaning on a different one: sp_configure … RECONFIGURE blocks, ALTER DATABASE … SET PARAMETERIZATION FORCED, ALTER DATABASE SCOPED CONFIGURATION, DBCC maintenance commands, WITH (NOLOCK) and index hints, OPTION (MAXDOP …), ON [PRIMARY] filegroup clauses, MySQL ENGINE=InnoDB and OPTIMIZE TABLE, Oracle /*+ hints */, TABLESPACE and STORAGE clauses. EQLServer accepts them, does nothing, and writes a line to the compatibility log instead of raising an error.

Report what is left, honestly.

Whatever cannot be absorbed by the interpreter or safely ignored ends up in the report as a named list, each item with a proposed code change and an effort estimate. An English-speaking database specialist then walks through the result with your team in a one-hour call: what the log means, what the open items cost, and what the migration path looks like. In practice the list is short, and it shrinks with every POC we run.

poc-compat.log — replay of 4,812 statements

RUN      4,655  statements executed identically
FIXED       97  interpreter patched during POC
IGNORED     54  engine-specific, logged, no error
OPEN         6  listed in report with estimate
────────────────────────────────────────────────────────────────────────────────
IGNORED  ALTER DATABASE CURRENT SET PARAMETERIZATION FORCED       optimizer setting, no-op
IGNORED  EXEC sp_configure 'show advanced options',1; RECONFIGURE server config, no-op
IGNORED  EXEC sp_configure 'cost threshold for parallelism',50    server config, no-op
IGNORED  EXEC sp_configure 'optimize for ad hoc workloads',1      server config, no-op
IGNORED  ALTER DATABASE SCOPED CONFIGURATION SET QUERY_OPTIMIZER_HOTFIXES=ON engine internal, no-op
IGNORED  SELECT … WITH (NOLOCK)                                   hint stripped
IGNORED  CREATE TABLE … ON [PRIMARY]                              filegroup clause dropped
FIXED    FORMAT(@d, 'dd.MM.yyyy', 'de-DE')                        culture arg added to interpreter
FIXED    STRING_AGG(…) WITHIN GROUP (ORDER BY …)                  ordering clause implemented
OPEN     CLR assembly dbo.GeoHash                                 proposal: rewrite as PL/Python, ~0.5 d
────────────────────────────────────────────────────────────────────────────────
application source files changed: 0

0changes in your source

97fixes shipped to all customers

6items left for the report

Example log for illustration; your numbers come from your statements. Every FIXED line becomes part of the next EQLServer build, so the compatibility list on this page grows with each POC.

Pricing

Three prices. One rule. No per-core, no per-seat, no surprises.

Every license is perpetual and paid once. Maintenance is an optional yearly subscription at the purchase price: updates, new dialects as they ship, and support. Skip a year and the license keeps running without it. All prices net of VAT.

Single deployment

Server

$250once per server · no limit on cores, RAM or database size

All six dialects in every database, reading and writing the same tables
No license limit on cores, RAM or database size, ever
Offline license file: no activation server, no phone-home
Unlimited databases per instance, licensed per computer
Monitoring, backup, HTTPS tunnel and updates by xcopy included
PostGIS available as a free, optional GIS module
E-mail support from database specialists, next business day
Optional maintenance: $250 / year · updates, new dialects, support

Get a license

For ISVs Ship it with your product

OEM

$5,000once · up to 50 customer installations included · no royalties, no seats

Everything in Server, for every installation you ship
Bundle EQLServer inside your own installer or ZIP
White-label folder, service and window names for your brand
Second-line support for your own support team
Your customer gets a full server for other applications (see below)
Condition: your product sells for at least $250 per installation
More than 50 installations: add installation packs, price on request
Optional maintenance: $5,000 / year · updates, new dialects, support

Get OEM

Own the stack

Source

$25,000once · full source code plus the build harness we use ourselves

Everything in OEM
Complete EQLServer source: all dialect layers, the SQLite DLL, Windows build, packaging
Build and test tooling: AI harness setup, test suites, POC replayer
Adapt the interpreter to your app yourself
Developer support from the team that builds EQLServer
Escrow included; use inside your products, redistribute as binaries
Conditions: product sells for at least $250, no competing database product
Optional maintenance: $25,000 / year · updates, new dialects, support

Talk about Source

Start here

Proof of Concept

$1,000once · fully credited against OEM or Source

Book a POC

We provide the VMWindows 11 with EQLServer already running.
You install your appHand over schema and a query log.
Automatic replayGaps are fixed in our interpreter where we can, with change proposals where we can't.
One-hour reviewAn English-speaking database specialist walks your team through the result.

Your product ships with a database server, not just a database.

Under OEM, the EQLServer instance you bundle counts as a full Server license for your customer — as long as your product sells for $250 or more. Your customer may put their own applications on it: the shop, the reporting tool, the Access front-end, the Python script. Six dialects, pgvector, the optional GIS module, no extra license. What used to be "requires SQL Server" on your datasheet becomes "includes a multi-dialect database server".

For you, that is a feature line you did not have to build. For your customer, it is one less server to buy, license and install.

OEM · the hidden upside

Your product now ships with a database server your customer can use for everything else.

Under OEM, every installation of your application includes a full EQLServer server license — no limit on cores, RAM or database size, all six dialects, pgvector, PL/Python. Your customer is free to put other workloads on it: the intranet on MySQL, a reporting tool on Postgres, a department tool that speaks T-SQL. You pay $5,000 once for up to 50 installations; your customers each receive what we sell for $250 per server, bundled into your product.

Sell it, don't hide it.

"Includes a multi-dialect database server for your other applications" is a line for your price list, not a footnote. It turns a cost item into a feature.

Raise the floor.

If your application sells for $250 or more, the included server alone covers the price your customer would pay for EQLServer directly — the rest of your product is pure margin on top.

Become the platform.

Once the customer's other data lives on your server, your application is the system the others integrate with — and the one nobody replaces lightly.

For comparison — list prices, October 2026

SQL Server 2025 Standard, 8 cores, perpetual$15,780

Oracle SE2, 2 sockets, perpetual + 1 yr support$42,700

InterBase ToGo Pro, unlimited redistribution$1,980 / yr

Source code for any of the abovenot available

EQLServer OEM, 50 installations included$5,000 once

Comparison figures are published list prices (Microsoft estimated retail, Oracle Technology Price List, ComponentSource for InterBase 15.1). Your negotiated prices may differ; the POC report uses your numbers.

Questions engineers ask first

The honest answers.

What exactly is EQLServer built on?

EQLServer is PostgreSQL 18 (the Babelfish fork) with Babelfish for T-SQL/TDS, substantially extended by us (see the next question), plus orafce. On top come EQLServer's own MySQL/MariaDB protocol layer, an Oracle compatibility mode, a SQLite replacement DLL, and a Firebird/InterBase protocol layer, all working on one shared catalog, so every dialect sees the same tables, views, functions and procedures. Upstream sources are pinned and updated deliberately, only after a full regression run across every dialect has passed. Your data is stored in a regular, standard PostgreSQL 18 data directory; T-SQL objects require the bundled Babelfish extensions to be present.

What about SQL Server features Babelfish does not cover?

Most of them are already covered. EQLServer handles far more T-SQL than even the latest upstream Babelfish release, because we have extended it substantially: missing syntax, built-in functions, data type behaviour and system catalog views. The result passes 99.5 % of the Babelfish T-SQL test suite. Every POC raises that further: what your application still needs is added to the EQLServer interpreter rather than your code, and the fix ships to every customer. Engine-specific statements are accepted and logged instead of failing; what remains is listed in the report with an estimate. We do not sell "100 % compatible"; we sell a verified list that grows with every POC.

How many databases does one server hold?

As many as you need. One EQLServer instance holds any number of databases, and all six dialects work in every one of them: one database per client company, one per fiscal year, a test database next to production or several hosted customers on one server. Cross-database queries such as Stock.dbo.Items joined with Client1.dbo.Invoices work as in SQL Server. MySQL sees each database as a database, Firebird and SQLite select it by path or file name, PostgreSQL clients by connection parameter. Each database can be backed up and restored on its own, and monitoring and the Performance Sentinel show every database separately. The license is per computer, so extra instances are included too.

MySQL is case-insensitive by default. Postgres is not. Who deals with that?

We do, in the dialect layer. Collation, identifier folding, AUTO_INCREMENT, ON UPDATE CURRENT_TIMESTAMP and lenient GROUP BY are handled so that unchanged applications behave exactly as they did on MySQL or MariaDB. MySQL stored procedures, functions and triggers run in their own syntax, so existing install scripts, plugins and migrations work as they are. The rules apply to MySQL connections only, which means a MySQL application and a T-SQL application can share the very same tables without forcing their conventions on each other. Anything that still differs during your POC is fixed in the interpreter or listed in the report with a concrete proposal and an estimate.

Can I write into a third-party app's tables from my dialect?

Yes, and you should do it the way you would with any shared schema: through views and triggers you own, not by bypassing the application's own logic. A typical pattern is a view in your schema that presents the shop's order table in your naming, and an INSTEAD OF trigger that writes back through the application's own rules, such as stock checks or status fields. Because every dialect sees the same rows inside one ACID transaction, your T-SQL code can update the MySQL shop and your own tables in a single commit, with no linked server and no sync job. The POC demonstrator shows this pattern on your own data and tables, so your team sees how two applications share rows and transactions safely.

Does the Oracle mode speak Oracle Net?

No. It is a dialect simulation: PL/SQL-style syntax, packages, Oracle functions, ROWNUM, CONNECT BY, sequences and the familiar date and string behaviour, accessed over the PostgreSQL protocol with any PostgreSQL driver. It is verified against the complete Oracle sample schemas, all 99 reference queries. That makes it a good fit for porting your own Oracle code and keeping it readable to the developers who wrote it. It is not a transparent drop-in for a third-party application that ships Oracle client binaries and expects an Oracle Net listener on port 1521; for those, the POC tells you honestly and up front whether a port is realistic and what it would cost in time and money.

How does the SQLite drop-in DLL behave?

Identically to real SQLite at the API level and in the sqlite3 shell: same exports, same return codes, same statement lifecycle, so your application does not notice the swap. The difference is that the data lives in EQLServer and is reachable from every other dialect, live and inside the same ACID guarantees, instead of sitting in a local file nobody else can read. Bulk inserts are batched automatically, so imports of millions of rows do not pay a network round trip per statement. Point several copies of the same desktop tool at one server and they share one database without file locking problems, which is usually the first improvement customers notice after the switch to EQLServer.

Does it replace the Firebird or InterBase server?

Yes. EQLServer listens on port 3050 and speaks the Firebird wire protocol, including Srp authentication for current clients and legacy authentication for older ones. Your existing fbclient, gds32 or ibclient, FireDAC, IBX, Jaybird or the .NET provider connect unchanged. PSQL procedures, generators, domains, computed fields and the RDB$ system tables are mapped onto the shared catalog, so IBExpert and FlameRobin show the object tree as expected. fbimport moves an existing database over, including procedures and triggers. After that, a Firebird trigger fires even when the row is inserted from T-SQL or MySQL, because every dialect writes into the very same physical table on one server.

Is the license clean enough to ship inside my product?

Yes. Everything in the server package is either our own code or under permissive open-source licenses such as PostgreSQL, Apache 2.0, MIT and BSD, with every copyright notice collected in THIRD-PARTY-NOTICES.txt. An automated license inventory runs on every build and fails it if a single file cannot be matched to a permitted license. PostGIS is GPL-licensed and is therefore a separate, optional GIS module that nothing else links against; it is not part of the Source license. No GPL component sits in the core server package, and no proprietary vendor binaries or headers ship with it, so you can bundle EQLServer inside a commercial product without legal surprises or extra obligations.

Can my customers use the bundled EQLServer for other things?

Yes, under OEM. If your product sells for $250 or more, the EQLServer instance you ship is a full Server license for that customer: they may connect other applications, in any of the six dialects, without buying anything from us. That covers the web shop on MySQL or MariaDB, a reporting tool on Postgres or a department tool that speaks T-SQL. Below $250, the instance is licensed for your product only. Either way, there is no per-customer fee: OEM covers up to 50 installations, and larger rollouts add installation packs. Your customer gets one database server instead of three, and you get a feature on your price list that you did not have to build, test or support yourself.

What exactly do I get with Source?

The complete EQLServer repository: our dialect layers for MySQL, Oracle and Firebird, the SQLite DLL, the Windows build and packaging, plus the build and test tooling we use ourselves: the AI harness setup, test suites and the POC replayer. You adapt the interpreter to your application the same way we do; changes to the interpreter flow back to us, and the result ships only as binaries inside your products. Two conditions apply: your product has to sell for at least $250, and the code may not be used to build a competing database product. Escrow is included, so the "what if you disappear" question is answered either way, and your team can keep building even if we stop.

What happens if I stop paying for updates?

Nothing. Every license is perpetual, and the license file works offline, so there is no activation server that could switch anything off. You keep running, and OEM customers keep shipping, the last version you received, for as long as you like. Maintenance only decides whether you receive new versions, new dialects and support; it never decides whether your existing installations work. Pick it up again in any later year you like at the same price, without paying for the years you skipped. Versions released while your maintenance was active stay yours forever, so an ISV who pauses maintenance for a year loses nothing that was already delivered to customers in the field and nothing ever stops.