2025: I'm joining MongoDB

I have 30 years of experience with SQL databases, including Oracle Database, Amazon RDS, PostgreSQL, and YugabyteDB. I am passionate about data modeling, troubleshooting performance issues, and advocating for developers. At Yugabyte, I've had the privilege of collaborating with incredible people on an exceptional product. I still believe in the future of Distributed SQL with PostgreSQL compatibility, but I've decided to embrace a new challenge. Data is everything, and my expertise in SQL databases enables me to assist developers in designing and building applications on document databases.

?I'm excited to share that I will be joining the MongoDB DevRel Team in February 2025.

My Journey to NoSQL and Document Databases

Before I made this decision, I discussed it with friends. Some of them, mainly the DBAs, were surprised by my choice and didn’t understand until I explained why I was excited to understand and help NoSQL developers and why the MongoDB Developer Experience team was interested in my SQL background. In contrast, my friends in development and DevOps found it to be a natural progression. They see it as a continuation of my work listening to developers and helping them build successful database applications. All those who have been working with MongoDB told me that I will enjoy it it.

Throughout my 30 years in the tech industry, I've been passionate about SQL databases—there hasn't been a single day without writing SQL in my work. My experience spans Oracle Database (from 7.1 to 19c, I'm an Oracle Certified Master and was an Oracle ACE Director), some AWS databases (I'm an AWS Data Hero), PostgreSQL, and YugabyteDB, along with sporadic troubleshooting with DB2, Sybase, Informix, SQL Server, and MySQL. I also studied some NoSQL databases like DynamoDB and Cassandra.

I only later recognized a key player missing from my experience: MongoDB. Given its remarkable popularity and success, it would be inconsistent to work in database developer relations and ignore the one that has gained such significant attention from developers. The success cannot be denied, given the company's accomplishment and developer adoption.

As with any technology, users require assistance to use it effectively, including training, coaching, and community engagement. Not only am I eager to learn more about the MongoDB database engine, but my extensive background in relational databases and data modeling for various applications can benefit these users. Whether you store your data in relational tables or document collections, you must understand how the engine works for your access patterns and efficiently design the application and data model.

The gap between SQL and NoSQL has narrowed in recent years. SQL databases have incorporated JSON data types to function like document databases for specific use cases. Meanwhile, NoSQL databases have added transactions and strong consistency to operate like ACID databases for other use cases. The primary difference lies in the API (Application Programming Interface): SQL (Structured Query Language) serves as a declarative language to get the database to process data, whereas MQL (MongoDB Query Language) offers developers a programming interface that allows greater control over data processing, in their application programming language.

SQL is an API to Code in the Database (Stored Procedures and Views)

If you are surprised by my decision to advocate for a NoSQL database, you may have overlooked an important point. While I've always been a fan of SQL, I have experienced a significant flaw: the developer experience. Collaboration between development and operations teams has consistently faced challenges, and SQL database vendors have not significantly enhanced the technology to address this issue for a long time.

SQL databases were designed when the RDBMS (Relational Database Management System) was the platform for storing and processing data. If users had some procedural logic, the code was shipped to the database as stored procedures written in a specific language (like Oracle PL/SQL) or through pre-compilers (like Oracle Pro*Cobol). The database was rich in features and leveraged the relational model and Codd's 12 rules. Still, the input and output to the user were far from ideal: SQL input with lists of scalar values and result sets presented as a single two-dimensional table, reminiscent of the old times of flat files. Unfortunately, the agility of relational data structures exists only within the database and is inaccessible outside it.

SQL databases were optimized for a database-centric design, but developers decided otherwise. They wanted to use other programming languages on platforms distinct from the RDBMS. It started with client/server deployments, and applications ran on Borland Delphi, Microsoft Visual Basic, PowerSoft PowerBuilder, and Gupta SQLWindows, to name a few that I used. This gave the developers a lot of freedom and agility but wasn't efficient because it required many network round trips with the database because of the SQL API (ODBC and SQL).

SQL Database Administrators' (DBA) answer was always the same:?you don't use the database correctly; move your code (business logic) into the database in stored procedures rather than interactive transactions. A stored procedure allows sending a single payload to the database, similar to a document created from user input forms. This can enable PL/SQL to insert or update several tables in one call. Views allow for the joining of multiple tables to render a single tabular result set. The application only needs to identify the duplicated columns to organize what is displayed across different grids in the user interface or printed in various report sections (you may remember the break command of SQL*Plus).

DBAs didn't listen to developers because they knew how to do it correctly with existing features, and developers didn't listen to DBAs because their solution didn't fit well with the modern developer environment.

This degenerated with object-oriented languages like Java, which improved the developer experience but increased the mismatch with the SQL API. Data input from UI forms and displayed on UI pages is easy to model as a hierarchical graph of objects. It would make sense to send such a data structure as one document to the database and retrieve a multi-level query result as one document with nested arrays and subdocuments. However, SQL and JDBC lack this feature, requiring converting high-level data structures to a low-level API with scalars and single-table result sets.

SQL didn't evolve for at least fifteen years before the database vendors offered new APIs like a REST endpoint (ORDS in Oracle Database) or more recent attempts (JSON-Relational Duality Views in Oracle Database). Still, it doesn't solve the problem encountered with PL/SQL: those new APIs are all proprietary, increasing the vendor lock-in. If it ever happens, it could take years to become an SQL standard. Fortunately, another solution came to help the developers interact with the database: Hibernate, JPA, and other Object-Relational Mapping frameworks for all languages. It releases vendor lock-in by supporting multiple database dialects, allows developers to declare and manipulate objects mapped to database entities, and synchronizes transparently with the database using SQL. Again, database vendors and administrators refused to understand the needs for this and maintained that the application development teams must code SQL queries and stored procedures. At?POUG 2023, I gave a presentation titled "Why do you hate Hibernate?" and explained to DBAs the importance of ORMs in addressing the overlooked SQL flows in developer experience.

In client-server deployments where multiple application versions operate simultaneously, the code must remain independent of the database schema. SQL databases feature a central catalog or dictionary that provides an abstraction layer for data independence. However, software architecture evolved to three-tier, and schema evolution is tied to application versions in the application server. The schema is described in the application code as JPA annotations, making the central catalog redundant and limiting scalability.

The Data Definition Language (DDL) was insufficient to migrate the schema for the frequent schema evolutions in modern applications. To get more flexibility and declare the schema in the application, developers used SQL databases as a simple key-value data store with an?Entity-Attribute-Value?model to be more flexible, but optimizing for an RDBMS query planner is impossible.

MongoDB is an API to Code Data Access in the Application

Finally, developers continued to process data in their applications using objects and ORMs, and the number of tables and joins increased. When the performance was not optimal and because the DBAs didn't listen to them, they concluded that the SQL database didn't scale and that the problem was SQL. While SQL database vendors and administrators continued to ignore them, one company focused entirely on the developer experience: MongoDB.

Instead of transforming application objects to SQL and connecting to databases that refuse to provide a better user experience, MongoDB offered a straightforward API that developers can access directly from the procedural, object-oriented language rather than writing abstract SQL in text strings. This API exchanges documents that are easily mapped to objects instead of a two-dimensional table result set.

Consider how you would insert an order with customer information and order lines in an SQL database:

This is easy to run from a CLI (Command-Line Interface), but in your application code, you must create this SQL transaction using character strings and run each command with ODBC or JDBC calls. To prevent SQL injection, you must use placeholder parameters and bind variables, which can only be scalar values rather than table rows or relational and nested structures. No syntax or type is checked at compile time. Any error will happen at runtime.

Here is what the SQL code looks like in the application code:

In MongoDB, the same transaction is executed with a single call involving a document constructed using the application programming language that describes the business object:

The MongoDB API is integrated into the programming language. Declaring the business object is even simpler in JavaScript, where the JSON structure is native:

Rather than using a translation layer like Object-Relational Mappers, MongoDB developed a storage engine specifically designed to store, index, transform, and retrieve documents in their native document format. Although SQL professionals may find the syntax challenging, it is often more intuitive for developers, which is what matters most. After investing significant time in teaching developers the language I've always used, SQL, I now see the importance of understanding the language developers favor and assisting them with data modeling in a document database.

This developer-centric approach offers numerous benefits. For example, SQL employs three-valued logic for NULL, which is mathematically interesting for representing unknown values but is too complex for developers working with code and data structures that use a two-valued logic. In contrast, MongoDB handles NULL like programming languages do. I have shared several examples in a recent blog post, and even SQL experts don't know how their database indexes null values:

The examples of transactions and null handling show how MongoDB simplifies tasks for database developers who have found SQL challenging. Although I don't regret learning SQL—having relied on it throughout my career—software engineering has evolved. Today's developers must be familiar with various languages and components and can't afford to learn one that behaves differently in many aspects. My role is to use my SQL experience to help them in data modeling for document databases.

Developer Advocacy, Awareness, and Enablement: Learning and Sharing

As I always did, I will keep sharing my learning experiences across various platforms, including blogs, videos, and conferences. I'll continue to look at some SQL databases such as Oracle, AWS RDS, PostgreSQL, and YugabyteDB—which has some impressive features in the 2025 roadmap, notably enhanced PostgreSQL compatibility. Nevertheless, most of my new content will center on document data modeling and MongoDB for developers.

If you’re an SQL user eager to learn and understand?MongoDB?or looking to expand your?expertise in document data modeling?and understanding of?performance, you may be interested in my publications. I'm also here to learn and look forward to your feedback. We can discuss these topics on?dev.to,?LinkedIn,???,?and social media. I hope we will meet and have some conferences, developer days, or design reviews.?I'm thrilled to join the MongoDB DevRel team.