In 2005 when Google was a $6.1 billion business, the database that underpinned the company\u2019s primary cash cow \u2013 it\u2019s AdWords online advertising platform that accounted for more than 95% of its revenue \u2013 was not keeping up with the growth of the company.\nTypically when a traditional database needs to scale, a process called sharding is used. It breaks data into multiple smaller databases to distribute load. More than a decade ago, the database powering AdWords was getting so large that one reshard took multiple years. A new database was needed. So Google built one.\n+MORE AT NETWORK WORLD: Deep dive on Amazon, Microsoft and Google cloud storage options | NoSQL takes the database market by storm +\nThis week Google has made the database it built to handle AdWords available to the general public as a product named Spanner. It comes during the nascent stages of a wave of new databases hitting the market that are similar to traditional, relational SQL databases, but they\u2019re much better at scaling to massive sizes. This new class has been appropriately dubbed NewSQL. And experts who track the database market believe they could one day give the giants of the database world, from Oralce, IBM and Microsoft, a run for their money.\n\nWhat Spanner is \nGoogle built Spanner to satisfy a number of criteria: It needed to be horizontally scalable to massive sizes and globally distributed in data centers around the world. Google also wanted a relational database that uses SQL \u2013 the popular database programming language; plus it needed to be low-latency and highly reliable. In 2012 after almost a decade of development, Google released a research paper describing Spanner and its use cases within Google.\nOver the next few years the company developed Spanner as a database offering from the Google Cloud Platform. Google released an initial beta of Spanner earlier this year.\nSpanner is a distributed database hosted in Google\u2019s cloud that is globally consistent and scalable. That means there can be instances of Spanner located around the world \u2013 so that data is close to end users who need to access it \u2013 but each copy of the database is the same. Doing so is much easier said than done.\nGoogle points to two unique qualities in its cloud that Spanner relies on to operate. One is to use a time-stamp method named TrueTime, which uses atomic clocks \u2013 the most accurate way of keeping time \u2013 to synchronize data around the world.\nSpanner also relies on Google\u2019s internal fiber network that connects Google\u2019s data centers around the world. Spanner\u2019s internal database traffic does not run on the public Internet, instead it runs through pipes built and controlled by Google, carrying only Google traffic. That gives Spanner internal traffic basically it\u2019s own high-speed highway to get anywhere in the world.\nThe NewSQL market \nSpanner is considered one of the first widely available cloud hosted NewSQL databases. NewSQL \u201crepresents the next chapter in the continuous development of database technologies,\u201d a paper authored by 451 Research Director Matt Aslett and Carnegie Mellon University\u2019s Andre Pavlo states.\nCharacteristics of NewSQL databases are not new, but they\u2019ve only been available in individual database types. Traditional relational databases support SQL and have strong consistency, but they do not scale well. NoSQL databases scale easily but lack support for SQL.\n\u201c(NewSQL databases) are by-products of a new era where distributed computing resources are plentiful and affordable, but at the same time the demands of applications is much greater,\u201d Aslett and Pavlo note.\nThe market for these new flavors of databases is still emerging. Perhaps the most notable example of NewSQL databases is SAP HANA, it\u2019s in-memory relational database. A handful of other newer companies offer NewSQL databases, including NuoDB, H-Store, Clusterix, VoltDB, MemSQL and others. Amazon Web Services offers Amazon Aurora, which supports MySQL and PostreSQL, which some consider NewSQL.\nOne of the advantages of NewSQL databases is they support applications that run on traditional SQL databases, such as Oracle\u2019s line of databases. Aslett and Pavlo point out, however that workloads running on those traditional databases are typically core applications that enterprises may be more reluctant to move to new databases unless there is a strong need to do so. NoSQL databases, on the other hand, excel at scalability and are typically used in new applications revolving around social, mobile and Internet of Things applications.\nAnalysts who track the NewSQL market still believe it will grow healthily in the coming years. Market Analysis, a research outfit in California, predicts 26% compound annual growth rate of NewSQL databases, reaching $1 billion by 2020. That is dwarfed by the traditional relational database management market, which IDC pegs as more than $30 billion annually. Customers with pain points from traditional databases are willing to invest in NewSQL for new workloads, though.\n\nSpanner in practice \nJDA, a supply-chain logistics firm, was one of Google\u2019s alpha testers on its public version of Spanner. The company helps customers plan when to make and ship product, and tracks product lifecycle around the world. \u201cIn our world, consistency is very important,\u201d says John Sarvari, JDA\u2019s Group VP of Technology. \u201cOur customers are making very important decisions based on their view of the data.\u201d JDA has no plans to phase out is existing relational databases, but Sarvari expects new applications and workloads could be built on Spanner moving forward. The biggest benefit of using Spanner, he says, is that it frees his staff up from having to manage databases that can become unruly to scale. \u201cWe just get this as a service from Google,\u201d he says, leaving staff to focus on the core competencies of what JDA provides to customers, instead of managing databases.\nSpanner costs $0.90\/node\/hour, plus $0.30\/GB\/month for storage. Spanner has a 99.99% uptime Service Level Agreement if deployed in a single region, and a 5 9s of availability if its spread across multiple regions.