Przed 1994 rokiem projektanci poszukujący systemów RDBMS opartych na językach SQL nie mieli szans na tanie rozwiązania. Rynek komercyjnych baz danych SQL zdominowany był przez systemy Oracle, Sybase i Infomix, przeznaczone do przetwarzania ogromnej ilości informacji połączonych złożonymi relacjami. Systemy te oferowały ogromną moc przetwarzania i mnóstwo funkcji, ale także pochłaniały dużo zasobów i były drogie. Koszt zasobów używanych przez wspomniane systemy liczony był w dziesiątkach tysięcy dolarów.

Duże korporacje i większe uniwersytety nie miały problemów z wydaniem kilku milionów dolarów w ciągu roku na ogromne serwery i oprogramowanie DBMS. Małym organizacjom i indywidualnym użytkownikom pozostawało zasiąść przed słabymi programami baz danych przeznaczonymi dla komputerów osobistych. W tym samym czasie istniało, co prawda na rynku kilka tanich systemów zarządzających bazami danych typu klient-serwer, jednak żaden z nich nie używał SQL-a jako języka zapytań. Najbardziej godnym uwagi był system, Postgres, wyprowadzonych z tych samych korzeni, co komercyjne oprogramowanie RDBMS Ingres.

Jako część swojej pracy doktorskiej na australijskim uniwersytecie Bond David Hughes stworzył system scentralizowanego monitorowania i zarządzania zróżnicowanymi systemami informatycznymi. Projekt ten nosił nazwę Minerva Network Managnent System. Kluczowym elementem Minervy był system DBMS, służący do przechowywania informacji na temat komputerów wchodzących w skład sieci. Hughes wykorzystał Postgres jako oczywiste rozwiązanie dla potrzeb swojej bazy. Jego koledzy sugerowali początkowo użycie języka SQL jako standardowego języka zapytań dla Minerwy. W końcu SQL był, i nadal jest, najszerzej akceptowalnym standardem wśród języków zapytań. SQL pozwoliłby Minervie na pozyskanie szerszego auditorium niż PostQUEL ograniczony wyłącznie do systemów „postgresowych”. Jak się z resztą okazało, nawet sam system Postgres „nawrócił się” obecnie na język SQL.

Dylemat pomiędzy wyborem standardu SQL a czynnikami ekonomicznymi zaprowadził Hughesa w ślepy zaułek. Gdyby oparł język Minervy na SQL nie miał by możliwości skorzystania z systemu obsługi baz danych. Ponieważ zakup oprogramowania RDBMS za kilka tysięcy dolarów nie wchodził w rachubę. Hughes zdecydował się na kreatywne rozwiązanie w postaci aplikacji na bieżąco tłumaczącej polecenia SQL na PostQUEL. Program ten przechowywał wyrażenia SQL wysyłane przez Minervę, konwertował je na PostQUEL, a tak uzyskane wyniki przesyłał do sytemu Postgres. Stworzony przez siebie produkt autor nazwał miniSQL lub mSQL.

Przez jakiś czas konfiguracja ta sprawowała się dobrze – przynajmniej dla potrzeb Hughesa. Minervy nie interesował rodzaj używanego systemu DBMS, do póki ten ostatni rozumiał polecenia SQL. Z punktu widzenia Minervy Postgres rozumiał język SQL. Niestety system Hughesa w miarę rozwoju ewoluował coraz wolniej. Stało się jasne, że Postgres – czy jaki kolwiek inny system RDBMS – nie będzie w stanie skutecznie obsłużyć skromnego zestawu funkcji Minervy w ramach dostępnych jej zasobów. Dla przykładu Minerva wymagała wielu jednoczesnych połączeń z bazami danych. Aby je obsłużyć Postgres musiał być uruchomiony równolegle w kilku kopiach serwera. Ponadto kilku potencjalnych udziałowców projektu Minerva, nie było w stanie zaangażować się w prace ze względu na to, że Postgres nie obsługiwał ich systemów, a zakup drugiego oprogramowania do obsługi baz danych SQL nie wchodził u nich w rachubę.

W obliczu tego problemu Hughes ponownie przemyślał decyzje użycia systemu Postgres. Złożony i duży, był prawdopodobnie zbyt skomplikowany dla potrzeb Minervy, której zapytaniami w rzeczywistości były proste wyrażenia. Hughes posiadał już translator języka SQL, czyli program mSQL. Przekształcenie go w serwer bazy danych, spełniający jego wymagania, wymagało jedynie uzupełnienia go o funkcje przechowywania i pobierania danych z bazy. Ewolucja ta doprowadziła mSQL do stanu, w którym znamy go dziś.