 All right, I'm Raj Vains. I had products at Clusterix, and I'll be talking about no SQL, not only SQL, using write tool for the job. The agenda is very simple. First, I'll tell you that SQL scales, just in case you've been living under a rock. And you actually won't know it from the previous talks. And the second thing is about some rules of thumb on how to pick the write tool for the job. So first, SQL scales. So for example, Clusterix has a client that has a 336 code deployment. It looks like a single SQL database to the application. It does transactions, real-time analytics, everything. They don't do any ETL. And they've been running on Clusterix for over 2 and 1 half years. So if we go down, the business goes down. So they rely on us. They write terabyte a day. They've got 100 million users, actually 15 to 20 million active. So SQL scales. If anybody tells you something else, you know, they're lying. OK. This is the second thing is rules of thumb. So the question is, which tool are you going to pick? So first is, what data do you want to store? And then what questions do you want to ask? So the world is kind of relational, for the most part. You have customers in e-commerce who place orders for products. Customers then write reviews for products. When you pull up products, you want to look at the reviews. And the customers who wrote them, that's a natural join. So a lot of your data is naturally relational. And in things like orders, all the orders are going to look pretty much the same. So relational makes a lot of sense. On the other hand, in some cases, the product catalog can have products which are very different. You might have flowers, and you might have a car. And they might not share that many characteristics. So use Mongo. It works really well. Or another document store, right? So that's the right mix. Pretty much nobody uses Mongo for the other part, and it might not make sense to use relational for that part. Second, how simply do you want your questions answered? This is off the web. That's a MySQL query, and there's a Mongo query. As you can see, the MySQL query is much simpler. It does the same thing, sends code to the data, does massively parallel processing, and you do not have to jump through hoops. So if you can use SQL for your case, for whatever you're trying to solve, use it. You don't have to do that. Third, when do you want your questions answered? So if you're doing reads and writes near real time and simple reads and writes, any database will work for you. That's not a big problem. If you want to do next-day analytics, you can ETL into Hadoop, use that. That's not a problem either. If you want to do real-time analytics, then it gets more interesting. But that's where the big data is moving too. If you have a SQL database, it can do real-time analytics as well, because SQL has that. No SQL will say they do aggregates or top tens, but, you know. And then you can use streaming analytics or something like that. You'd have to put a solution like that. Moving on depends on what size and flexibility do you want. So if you've got tens of terabytes of data, SQL will work just fine. You want the petabyte analytics, use Hadoop. Then is the question of flexibility. As you get more flexibility, you lose your ability to query. For example, if you're using SQL, you have a relational schema, but you can make changes to it online, right? You get joints, complex analytics, based on statistics as you add data. The query planner will choose a different plan for you. You can get more flexibility, and in some cases that is good, but remember what you're losing. You can't do any of that stuff. You can only do simple or index lookups. Then is the question of what guarantees do you need? So we were kind of in the space where we said, all right, use transactions for everything. You didn't need them for everything. Then we moved to like, all right, noSQL is great. Use noSQL for everything. And then you go like, you know. And then you're like, ah, you know, transactions are kind of good for some stuff. So use what you need. If you need transactions, use transactions. If you don't need them, but you know, don't use noSQL where you need transactions. Then is geographic requirements, right? If you are setting up a multi-master, you might need to give up asset properties. And if anybody tells you otherwise, it's not right. So, you know, then you can decide what's the right solution. I'm running short of time. So summary, SQL and noSQL both work. Art is in getting the combination right, okay? So a single SQL database will do reads, writes, inserts, analytics, scale to tens of terabytes. And please don't do sharding. It's a waste of human effort. And it will be poorer than using a database. On the other hand, you'll use noSQL help for caching if you need higher flexibility or if you need petabytes for analytics. That's the perfect time.