A tool for easy online testing and sharing of database problems and their solutions.

Who should I contact for help/feedback?

There are two ways you can get in contact:

  • Email : info@zzzprojects.com
  • Twitter: @sqlfiddle

What am I supposed to do here?

If you do not know SQL or basic database concepts, this site is not going to be very useful to you. However, if you are a database developer, there are a few different use-cases of SQL Fiddle intended for you:

You want help with a tricky query, and you'd like to post a question to a Q/A site like StackOverflow. Build a representative database (schema and data) and post a link to it in your question. Unique URLs for each database (and each query) will be generated as you use the site; just copy and paste the URL that you want to share, and it will be available for anyone who wants to take a look. They will then be able to use your DDL and your SQL as a starting point for answering your question. When they have something they'd like to share with you, they can then send you a link back to their query.

You want to compare and contrast SQL statements in different database back-ends. SQL Fiddle easily lets you switch which database provider (MySQL, PostgreSQL, MS SQL Server, Oracle, and SQLite) your queries run against. This will allow you to quickly evaluate query porting efforts, or language options available in each environment.

You do not have a particular database platform readily available, but you would like to see what a given query would look like in that environment. Using SQL Fiddle, you don't need to bother spinning up a whole installation for your evaluation; just create your database and queries here!

How does it work?

The Schema DDL that is provided is used to generate a private database on the fly. If anything is changed in your DDL (even a single space!), then you will be prompted to generate a new schema and will be operating in a new database.

All SQL queries are run within a transaction that gets immediately rolled-back after the SQL executes. This is so that the underlying database structure does not change from query to query, which makes it possible to share anonymously online with any number of users (each of whom may be writing queries in the same shared database, potentially modifying the structure and thus -- if not for the rollback -- each other's results).

As you create schemas and write queries, unique URLs that refer to your particular schema and query will be visible in your address bar. You can share these with anyone, and they will be able to see what you've done so far. You will also be able to use your normal browser functions like 'back', 'forward', and 'reload', and you will see the various stages of your work, as you would expect.

What differences are there between the various database options?

Aside from the differences inherent in the various databases, there are a few things worth pointing out about their implementation on SQL Fiddle.

MySQL only supports queries which read from the schema (selects, basically). This is necessary due to some limitations in MySQL that make it impossible for me to ensure a consistent schema while various people are fiddling with it. The other database options allow the full range of queries that the back-end supports.

SQLite runs in the browser; see below for more details.

What's up with that [ ; ] button under each panel?

This obscure little button determines how the queries in each of the panels get broken up before they are sent off to the database. This button pops open a dropdown that lists different "query terminators." Query terminators are used as a flag to indicate (when present at the end of a line) that the current statement has ended. The terminator does not get sent to the database; instead, it merely idicates how I should parse the text before I execute the query.

Oftentimes, you won't need to touch this button; the main value this feature will have is in defining stored procedures. This is because it is often the case that within a stored procedure's body definition, you might want to end a line with a semicolon (this is often the case). Since my default query terminator is also a semicolon, there is no obvious way for me to see that your stored procedure's semicolon isn't actually the end of the query. Left with the semicolon terminator, I would break up your procedure definition into incorrect parts, and errors would certainly result. Changing the query terminator to something other than a semicolon avoids this problem.

Why are there two strange-looking options for SQLite?

SQLite is something of a special case amongst the various database types I support. I could have implemented it the same way as the others, with a backend host doing the query execution, but what fun is that? SQLite's "lite" nature allowed for some interesting alternatives.

First, I found the very neat project SQL.js, which is an implementation of the engine translated into javascript. This means that instead of using my servers (and my limited memory), I could offload the work onto your browser! Great for me, but unfortunately SQL.js does have a few drawbacks. One is that it taxes the browser a bit when it is first loaded into memory. The other is that it doesn't work in all browsers (so far I've seen it fail in IE9 and mobile Safari).

The other option is "WebSQL." This option makes use of the SQLite implementation that a few browsers come with built-in (I've seen it work in Chrome and Safari; supposedly Opera supports this too). This feature was considered part of the W3C working draft for HTML5, but they depricated it in favor of IndexedDB. Despite this, a few browsers (particularly mobile browsers) still have it available, so I figured that this would be a useful feature to grab onto. The advantage over SQL.js is that it is quite a bit faster to load the schema and run the queries. The disadvantage is that it isn't widely supported, and likely not long for this world.

Together, these two options allow SQLite to run within any decent browser *cough*IE*cough*. If someone links you to a SQLite fiddle that your browser doesn't support, just switch over to the other option and build it using that one. If neither works, then get a better browser.

Who built this site, and why?

profile for Jake Feasel at Stack Overflow, Q&A for professional and enthusiast programmers

SQLFiddle.com was built by Jake Feasel, a web developer originally from Anchorage, Alaska and now living in Vancouver, WA. He started developing the site around the middle of January, 2012.

He had been having fun answering questions on StackOverflow, particularly related to a few main categories: ColdFusion, jQuery, and SQL.

He found JS Fiddle to be a great tool for answering javascript / jQuery questions, but he also found that there was nothing available that offered similar functionality for the SQL questions. So, that was his inspiration to build this site. Basically, he built this site as a tool for developers like me to be more effective in assisting other developers.

How is the site paid for?

ZZZ Projects started to pay for the hosting in 2017 before taking the ownership in 2018. We have some great plan to make SQL Fiddle even more friendly user, and we welcome any contribution.

Source Code

If you are interested in the fine details of the code behind SQL Fiddle and exactly how it is deployed, it is all available on github

What platform is it running on?

This site uses many different technologies. The primary ones used to provide the core service, in order from client to server are these:

Title Description
RequireJS js JavaScript module loader and code optimizer.
CodeMirror js For browser-based SQL editing with text highlighting.
Bootstrap css Twitter's CSS framework (v2).
LESS css CSS pre-processor.
Backbone.js js MV* JavaScript framework.
Handlebars.js js JavaScript templating engine.
Lodash.js js Functional programming library for Javascript.
Date.format.js js Date formatting JavaScript library.
jQuery js AJAX, plus misc JS goodness. (Also jq plugins Block UI and Cookie).
html-query-plan js XSLT for building rich query plans for SQL Server.
Varnish backend Content-caching reverse proxy.
Vert.x backend Open Source Java-based Application Server.
PostgreSQL db Among others, of course, but PG is the central database host for this platform.
Grunt devops Javascript task runner, config and frontend build automation.
Maven devops Dependency management, backend build automation.
Docker devops VM management.
Amazon AWS hosting Cloud Hosting Provider.
GitHub devops hosting Git repository, collaboration environment.

This list doesn't include the stacks used to run the database engines. Those are pretty standard installs of the various products. For example, I'm running a Windows 2008 VPS running SQL Server 2014 and Oracle, and various Docker images running the others.