What are alternatives to SQL database storage for a web site?

An SQL database is overkill if your storage needs are small. When I was young and dumb, I used a text file and flock()ed it when I needed to access it. This doesn’t scale, but I still feel that non-database solutions have been completely ignored in Web 2.0.

Does anyone not use an SQL database for storage? What are the alternatives?

HTML5 Web Storage and Web SQL Database

Is it possible to store the information in both Web Storage and Web SQL forever because it deletes the information after the user clears the browsing data. if its not possible what should i do to fix

what is the best approach to store database row into html5 web storage and not web sql database [closed]

We would like to evaluate the size of our data after storing it in html5 web storage. Our data is fetched from database.What would be the best way to store data from database into Html5 Web Storage. W

Client Side Storage with Web SQL Database

My application uses client side database storage using webSQL to store information for the user. I have heard that browsers are starting to turn away from webSQL. Currently only chrome, safari and Ope

Local Storage, Session storage, Web storage, web database and cookies in HTML5

HTML5 local Storage HTML5 session storage HTML5 web storage HTML5 web database Cookies What is the difference between these concepts? Which case should I use one in particular? Which are the differen

what is database STORAGE ENGINE

I heard about database storage engines and those are appending to table while creating a table. What actually A Database Storage Engine. I heard these two MyISAM Storage Engine InnoDB Storage Engine T

What’s the best performance SQL database for data storage on CentOS 246MB RAM, Apache and PHP? [closed]

What’s the best performance SQL database for data storage on CentOS 246MB RAM, Apache and PHP, json_encode() with using less RAM as possible? Maybe some NoSQL database, UnQL? On right now I use MySQL,

Alternatives to using Web SQL database for storing large amount of data in Phonegap app?

Problem Statement :- 1) The app is developed in Phonegap to support multiple devices (Android,iOS etc) 2) Currently using Web SQL database due to large amount of data 3) App will have to receive updat

Web SQL Storage in iphone

Can I use a Web SQL Storage in iPhone Currently my following code is resulting in error <!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-tran

GWT client-side HTML5 database storage (Web SQL Database)

I wonder if there is an API for using Database Storage in GWT 2.x or I should use native code like this instead? var database = openDatabase(Database Name, Database Version); database.executeSql(

SQL Database storage in web browser Javascript/HTML5

I have a problem displaying the results after executing a query in a SQLite database which is created on the run. Here is my code CREATING DATABASE var mydb=false; // initialise the database initDB =


I would check out XML if I were you. See w3schools XML tutorial section on the left side. Tons of possibilities without using SQL database.

It probably depends how dynamic your web site is. I used wiki software once that used RCS to check in and out text files. I wouldn’t recommend that solution for something that gets as many updates as StackOverflow or Wikipedia. The thing about database is that they scale well, and the database engine writers have figured out all the fiddly little details of simultaneous access, load balancing, replication, etc.

A distributed hash table like google bigtable or hadoop is a simple and scalable non SQL database and often suits the websites far better than a SQL database. SQL is great for complex relational data, but most websites don’t have this requirement. Most websites store and retrieve data in a few forms and don’t need to run complex operations on the data.

Take a look at one of these solutions as they will provide all of the concurrent access that you need but don’t subscribe to the traditional ideas of data normalisation. They can be thought of as pretty analogous to a bunch of named text files.

There are a lot of alternatives. But having SQLite which gives you SQL power combined with no fuss of file based storage, there is no need to look for these alternatives. SQLite is light enough to be used in cell phones and MP3 players, so I don’t see how it could be considered an overkill.

So unless your application needs something very specific, don’t bother. Most alternatives are a lot harder to use and have less performance.

I would say that it doesn’t depend on whether you store less or more information, it depends on how often you are requesting the stored data. Databasemanagers are superb on caching queries, so they are often the better choice performance wise. How ever, if you don’t need a dynamic web page and are just loading static data – maybe a text file is the better option. Which format the data is stored in (i.e. XML, JSON, key=pair) doesn’t matter – it’s I/O operations that are performance heavy.

When I’m developing web applications, I always use a RDBMS as the primary data holder. If the web application don’t need to serve dynamic data at every request, I simply apply a cache functionality storing the data in a cache file that gets requested when no new data have been added to the primary data source (the RDBMS).

Check CouchDB.

CouchDB (http://couchdb.apache.org/index.html) is a non-sql database, and seems to be a popular project these days, as well as Google’s bigtable, or GT.M (http://sourceforge.net/projects/fis-gtm) which has been around forever.

Object databases abound as well; dbforobjects (http://www.db4o.com/), ZODB (http://www.zope.org/Products/StandaloneZODB), just to name a few.

All of these are supposedly faster and simpler than traditional SQL databases for certain use cases, but none approach the simplicity of a flat file.

I have used LINQ to XML as a data source in a .NET project. It was a small solution, and used caching to mitigate performance concerns. I would do it again for the quick site that just needs to keep data in a common place without increasing server requirements.

SQLite is invented for this.

It’s just a flat-file that contains a complete SQL database. You can query, update, insert, delete, there’s little to no overhead in installation and all you need is the driver (which comes standard in PHP )

SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine.

Kind of weird that nobody mentioned this already?

Depends on what you’re storing and how you need to access it. Generally sql provides great reporting and manual management ability. Almost everything needs some way to manage what’s stored and report on it.

It depends what you are storing. My blog uses Blosxom (written in Perl but a similar thing could be done for PHP) where each individual entry is a separate text file. The first line is plain text (the title) and the rest is unrestricted HTML. Following a few simple rules, these are rendered to form a simple but effective blogging framework.

It does have drawbacks but it also means that each post is a discrete file, which works well for updating on a local machine and then publishing to a remote web server. This is limited when it comes to efficient querying though, so certainly not a good choice if you want fine-grained control and web-based interaction with your data.

I wouldn’t choose whether to use an SQL database based on how much data I wanted to store – I would choose based on what kind of data I wanted to store and how it is to be used.

Wikipeadia defines a database as: A database is a structured collection of records or data that is stored in a computer system. And I think your answer lies there: If you want to store records such as customer accounts, access rights and so on then a DB such as mySQL or SQLite or whatever is not overkill. They give you a tried and trusted mechanism for managing those records.

If, on the other hand, your website stores and delivers unchanging file-based content such as PDFs, reports, mp3s and so on then simply storing them in a well-defined directory layout on a disk is more than enough. I would also include XML documents here: if you had for example a production department that created articles for a website in XML format there is no need to put them in a DB – store them on disk and use XSLT to deliver them.

Your choice of SQL or not will also depend on how the content you wish to store is to be retrieved. SQL is obviously good for retrieving many records based on search criteria whereas a directory tree, XML database, RDF database, etc are more likely to be used to retrieve single records.

Choice of storage mechanism is very important when trying to scale high-traffic site and stuffing everything into a SQL DB will quickly become a bottleneck.

One level down from SQL databases is an ISAM (Indexed Sequential Access Method) – basically tables and indexes but no SQL and no explicit relationships among tables. As long as the conceptual basis fits your design, it will scale nicely. I’ve used Codebase effectively for a long time.

If you want to work with SQL-database-type data, then consider FileMaker.

In Perl I use DBM or Storable for such tasks. DBM will update automatically when variable is updated.

A Simple answer is that you can use any data storage format, from standard defined, to database (which generally involved a protocol), even a bespoke file-format.

There are trade-offs for every choice you make in IT, and certainly websites are no different. In the early 2000’s file-based forum systems were popular as it allows anyone with limited technical ability to edit pages and posts. Completely static sites swiftly become unmanageable and content does not benefit from upgrades to the site user-interface; however the site if coded correctly can simply be moved to a sub-directory, or ripped into the new design. CMS’s and dynamic systems bring with them their own set of problems, namely that there does not yet exist a widely adopted standard for data storage amongst them; that they often rely on third-party plugins to provide features between design styles (despite their documentation advocating for separation of function & form).

In 2016, it’s pretty uncommon not to use a standard storage mechanism, such as a *SQL RDBMS; although static site generators such as Jekyll (powers a lot of GitHub pages); and independent players such as October CMS still provision for static file-based storage.

My personal preference is to use an *SQL enabled RDBMS, it provides me syntax that is standardised at least at the vendor level, familiar and powerful syntax, but unlike a lot of people I don’t think this is the only way, and in most cases would advocate for using a site-generator to save parts that don’t have to be dynamic to a static store as this is the cheapest way to live on the web.

TLDR; it’s up to you, SQL & RDBMS backed are popular.