Which type of database does your vendor rely on?

In the majority of cases users have no direct access to database back-end that their system uses for data organization/storage. Usually you manipulate data with interface or API. One can say it doesn’t really matter from the end user standpoint.

But still the choice of the database back-end defines system possibilities and ideology in many respects. This is the reason why I questioned vendors of products I review in my blog which database they use (if any), the reason of their choice and what kind of advantages it offers.

Avi Bryant from Dabble DB:

"We use a custom, in-memory object database. This allowed us to more easily provide the flexible data migration, sophisticated data types, and fast interactive querying that we wanted to offer our users."

Frank Zamani from Caspio Bridge:

"Caspio utilizes Microsoft SQL Server for its database. From day one, back in 2000, we knew that employing a powerful and scalable database is of utmost importance to us. We initially chose Oracle but soon encountered issues operating Oracle on a Microsoft stack. As a result in, our next release we dropped Oracle and replaced it with SQL Server.

The criteria remain high reliability and high scalability within a Microsoft stack. The result of our choice is evident in our ability to power some of the most demanding web applications for our enterprise customers."

Jim Salem from QuickBase:

"QuickBase chose to build a proprietary database to store app data. There are three reasons:

1) Scalability
Traditional relational database platforms are targeted towards supporting a relatively small number of potentially very large databases. Because of this, they run into significant scalability challenges when trying to host millions of independent databases. QuickBase’s architecture avoids these traditional scalability issues entirely. It can continue to support more and more applications just by adding additional hardware. Our application density (number of active applications hosted per server) is significantly higher than other online databases.

2) Performance
We chose an "in memory database" architecture because it’s significantly faster (and simpler) than traditional database architectures for the size problems that QuickBase targets.

3) Native Support for Easy-to-Use Web Data Types
We wanted to avoid the complexity of traditional databases leaking through into QuickBase’s UI. Unlike traditional databases, QuickBase was built from the ground up with the web in mind. Primitive QuickBase data types include email addresses, URLs, and versioned file attachments. These all require special coding (and overhead) on traditional databases. In addition, we implemented an easy-to-use relationship model that our users find simpler than the SQL "join" operations and index configuration required on traditional databases."

Chris Basham from TrackVia:

"TrackVia is built on the LAMP stack (Linux / Apache / MySQL / Perl).
The reason that we chose the LAMP stack is that TrackVia is differentiated from our competition by 1) Security, 2) Uptime, 3) Fast page loads.

Unlike many technology companies, we actually don’t want to have our service run on the newest technology that’s available. We only want our service to rely on mature, "battle tested" technologies that have been around for so long that all of the bugs have already been discovered and fixed. For example, we don’t run the most current version of MySQL. We run an older version that’s more stable and predictable.

As a result of this philosophy, we are able to truly deliver on the 3 items above – security, uptime and fast page loads."

Kirill Bondar from TeamDesk:

"We are using Microsoft SQL Server for TeamDesk.

In fact, we are using it for all our products for about 8 years. It proves itself reliable and scalable, delivers good performance in almost every case and provides tight integration with server platform, web environment and development tools.

Just one fact: rather than storing formula or summary column evaluation results and tracking the changes in dependend columns to know when the value needs recalculating, TeamDesk, thanks to Microsoft SQL Server performance, just calculates it on the fly. Even with large data sets and a lot of interconnected tables, this way rarely causes performance problems."

Yoge from Zoho Creator:

"We use our proprietary grid storage that is based on MySql. The reason for our choice is open source solution allow us to scale the performance to the desired level."

Treff LaPlante from WorkXpress:

"We use MySQL. We began our R&D in 2001 on MS SQL backend, and in 2003 switched to MySQL. We made the switch primarily because we knew we wanted to save our customers licensing costs, however, it's turned out to be a great decision on many levels. First, MySQL has a talented user community that we interact with to share knowledge and code. Second, MySQL has established itself in recent years with all manner of enterprise as an accepted and in some cases preferred database. Finally, the available packages and options for MySQL have greatly accelerated our time to market with new feature sets."

Aditya Tandon from Wolf Frameworks:

"We support Microsoft SQL Server and MySQL database. Currently for our OnDemand model, we offer the MySQL database which helps to lower cost for our customers. For us, database is storage and we plan to add support for other databases soon."

Paula Selvidge from PerfectForms:

"When we began development of PerfectForms in 2006, we primarily evaluated Oracle vs SQL and chose SQL due to the factors outlined below. We are also going to support SQL Express by year end, since it will further reduce costs for our customers who want to pursue an on-premise solution.

We chose SQL over Oracle due to:

1. Reliability and scalability
2. Lower cost for customers
3. Consistency with our MS stack
4. Our API is built on asp.net, so going with SQL offered better performance
5. Less costly from a support, maintenance and resource perspective for us internally."

I hope you’ve enjoyed reading all the answers as I did. Frankly, I don’t want to make any conclusions here. But I think this information can help you choose the system that is of better use for you.

So, you can check out the summary on back-end database vendors provided us with:

Dabble DB	Custom, in-memory object database
Caspio Bridge	Microsoft SQL Server
QuickBase	Custom proprietary database
TrackVia	MySQL
TeamDesk	Microsoft SQL Server
Zoho Creator	Custom storage based on MySQL
WorkXpress	MySQL
Wolf Frameworks	MySQL (for hosted service option)
PerfectForms	Microsoft SQL Server