

Google App Engine to support SQL - scorpion032
http://groups.google.com/group/google-appengine/browse_thread/thread/9740dd2a8bdf4206

======
ultrasaurus
Reading between the lines, this shows that App Engine is a growing &
responsive project, and makes me less nervous about building on it.

~~~
grandalf
I'm trying to feel that way too... but the fact is there are people on the app
engine team who could write SQL support for app engine in a few days in their
spare time.

The problems with app engine and the datastore have shown that there was a
high level misunderstanding underlying the core design of the datastore... and
how it would function in the context of lots of simultaneous users.

So I'd feel a lot more confident if Google addressed this concern other than
with the high availability datastore...

------
ShabbyDoo
Look at this from the perspective of Google Apps corporate users. Imagine that
the IT intern has just completed the corporate cafeteria's lunch menu system,
and it's time to deploy it. While it's then least significant application the
IT department manages, there's still a high fixed labor cost for
infrastructure roll-out and management. The DBA must provision instances
across dev, QA, and production environments. Onto which servers will the
application be deployed? Must they be procured? Even if the lunch menu app is
deployed on a VM instance, that OS image still requires security patches and
other upgrades. The cost of deploying the intern's work likely exceeds his/her
salary for the summer.

With SQL on AppEngine, corporate developers can build apps like this without
learning how to use NoSQL for persistence. Even if GAE's SQL doesn't allow
scale-out sufficient for SaaS vendors and such, it will fill an important
niche in Google's apparent goal of moving corps onto their cloud. As another
commenter here suggested, the bar for perf/scale in many cases may be no
higher than that provided by a MSAccess DB hosted on a Windows fileshare.

------
hpaavola
We are living weird times. Multitasking, copy/paste, SQL support, these things
are old, but still newsworthy when added to new platforms/services.

~~~
scorpion032
There is a difference between humans speaking and monkeys speaking. For
hundreds of thousands (if not millions) of people that use the datastore API,
this is a big thing.

------
jjm
This could help out those who are building projects using Django &/or Django-
nonrel.

~~~
zoomzoom
Kind of kills one of the main reasons for the nonrel branch to exist, no?
Wasn't django-nonrel an outgrowth of efforts to put django on appengine?

I think that the nonrel project has utility on other places (redis, mongo,
etc...) but ABP (all buttons pressed, creators of nonrel) was pushing django
on GAE alot, IIRC.

~~~
jjm
I agree. Don't forget that work has begun for a Cassandra driver as well.

Truth be told however, Django and a SQL based system aren't all that bad.

No matter what, it will be a long time before Django gets full 1.0 support for
NoSql in any shape or form. That means, 100% Django coverage.

------
callahad
So long as the performance is reasonable, this will go a long way towards
removing lock-in barriers with AppEngine.

~~~
tantalor
"The datastore is high-latency and extremely unreliable" \- <http://www-cs-
students.stanford.edu/~silver/gae.html>

~~~
pjscott
I've found that, if you want to make responsive apps on GAE, you must use
memcache. At any scale. Personally, I gave up and left for better options. The
generous free quotas aren't worth the trouble.

I hear they've improved latency since I left, so take this with a grain of
salt. I'm still not going back any time in the next few years, though.

------
netmau5
Hopefully this is the real deal and not an abstraction on the current
datastore. When using the datastore in a relational way, you get some pretty
horrid performance.

~~~
Strom
It is the real deal and it will scale, and I quote, "as well as SQL scales".

~~~
scorpion032
The "free scaling" using appengine datastore is nothing more than theoretical
at this point. The service has severe datastore latency problems and non
trivial downtime. Looks like using RDBMS, solves both these issues for now,
while Google can ponder around long term solution for the bigtable access.

------
Stormbringer
I rather got the feeling that the datastore was much better for certain kinds
of things than SQL. However, unless you are an expert in both SQL and the use
of BigTable, how would you know when to use the one over the other? Okay, so
obviously SQL is 'designed' to be good at transactions (whether it is or not
is an exercise for the readers), and BigTable is really good for fuzzy search.

I'm guessing that SQL is actually going to be more useful for anyone doing
e-commerce (hence transactions) or anyone with familiarity with traditional
SQL based persistence (even - shock horror - JDBC).

SQL is bland, BigTable is sexy. But another word for bland is mature...

------
redstripe
Nice feature, but not super important for new projects. I suppose it will make
porting some existing projects over.

I didn't remember seeing SQL on the roadmap however so I had another look (
<http://code.google.com/appengine/docs/roadmap.html> ) and I'm very excited to
see it as been revised with a few awesome enhancements. I've had several
projects I wanted to try on app engine which were impractical because of GAE
limitations like no full text search, no programmatic access to blobstore, no
bulk export/backup, no mapreduce. The future is looking a lot brighter for
GAE.

~~~
ibejoeb
Why isn't it important for new projects? I have a ton of projects that I can't
do on GAE precisely because of this. GQL is _extremely_ limited.

~~~
URSpider94
At the risk of re-hashing a number of previous discussions, GQL appears
limited when compared to SQL because Google's database is designed to scale to
extremely large datasets and massive numbers of concurrent users. The features
that are missing were removed intentionally because they don't scale. If you
can re-think your database use to be consistent with this new paradigm, then
you'll have a much more scaleable app when you're done.

~~~
scottbessler
The end goal for every app doesn't have to be scaling on the order that GAE's
original design provides. People have lived for years creating apps that use
Excel or Access as a datastore.

Being able to use SQL on GAE will allow more widespread use of GAE for things
besides "the next twitter".

------
Kilimanjaro
Google should buy a SQL engine like Postgres now that mySQL is in oracle's
hands. People will need SQL databases till the end of times, and coupled with
BigTable that can be a killer in the database space.

