Live data from Hacker News

Viewing profile — GabeWeiss_

GabeWeiss_

HN member
Joined
Tue, Mar 13, 2018, 4:52 PM UTC
HN karma
150
Public activity
66 items

About GabeWeiss_

No profile information was provided.

Recent public activity

  1. comment
    Comment #37851698

    Fair enough, I'm not (obviously) as familiar with the AWS systems and how the price to performance ratio works out for all the products.

  2. comment
    Comment #37850596

    Of course, I was simplifying. It's always more complicated doing a migration. :)

  3. comment
    Comment #37850470

    Yes, but QPS vs. "queries to the API". The difference is the time slice. I should have been more explicit. The key here really is the time function between the numbers. That the AW…

  4. comment
    Comment #37850422

    Parts, yes. In reference to the specifics mentioned in here though, those services run on Infra Spanner, not Cloud Spanner, but they're the same stack. The main reason things like …

  5. comment
    Comment #37850355

    Tell me more (bonus points if you find me on LinkedIn or other social because tracking comment responses on HN is really rough). I'd love feedback you have so I can bring it back t…

  6. comment
    Comment #37850341

    Really glad to hear! Please find me on social media or LinkedIn and let me know how it goes for you using the PG layer. I'd love to hear more feedback.

  7. comment
    Comment #37850329

    You can! Spanner has a free trial: https://cloud.google.com/spanner/docs/free-trial-instance . Keep in mind, that per-request pricing isn't free unless you stay under the free tier…

  8. comment
    Comment #37850318

    The DeWitt clause is only there to prevent badly written performance data from getting attention it shouldn't. If anyone writes a good benchmark (good process, not good results, ne…

  9. comment
    Comment #37850155

    More specifically, infra and cloud Spanner are the same stack. So they've progressed together hugely since 2013. :) The real differences between the two are more about the internal…

  10. comment
    Comment #37850084

    But that's kind of a moot point. I mean, if you're even looking at the likes of DynamoDB or Spanner, it's because you need the scale of those engines. PostgreSQL is fantastic, and …

  11. comment
    Comment #37850056

    100% this, and even though I work for Google I absolutely agree. BUT, for the folks that need it, PostgreSQL just DOESN'T cut it, so it's why we have databases like DynamoDB, Spann…

  12. comment
    Comment #37849949

    True, but one would hope that both sides in this case would be putting their best foot forward. Getting peak performance out of right sizing your DB is part of that discussion. I c…

  13. comment
    Comment #37849899

    Infra and Cloud Spanner are the same stack. Having those services run on infra is more about the legacy of tooling to shift it rather than anything around performance or ability to…

  14. comment
    Comment #37849895

    Infra and Cloud Spanner are the same stack. Having those services run on infra is more about the legacy of tooling to shift it rather than anything around performance or ability to…

  15. comment
    Comment #37849844

    Just as a hand in the air...Be careful about what you're comparing here. # of API calls over a period of time is...largely irrelevant in the face of QPS. I can happily write a DDOS…

  16. comment
    Comment #35379505

    My PM also reminded me, depending on the data set size too, if it's bigger than the buffer cache, we might see some improvements over PG as well from that (we've made memory improv…

  17. comment
    Comment #35379479

    I'm assuming you mean "I start using this under a free dev license, and want to shift up to the paid production version"? And what that looks like? If that's the case, I don't know…

  18. comment
    Comment #35379438

    The improvements we've made on the read side of things likely won't affect the geo data directly, BUT, depending on what other aggregate data you're combining with the geo data you…

  19. comment
    Comment #35373769

    It really is, yes. I can't go into a lot of detail on the "why" because it's not open source and the product team would murder me...but I highly encourage folks to try it for thems…

  20. comment
    Comment #35373732

    As a heads up, we're unlikely to make the codebase for it open. I might be able to convince the product team to open source some components of it (our GM has talked about this befo…

  21. comment
    Comment #35363321

    No worries on the negativity! I totally understand. No one likes to have time wasted. :( I'm getting the more detailed info on the cache use-case to the eng team just so they're aw…

  22. comment
    Comment #35363258

    We don't have specific details yet about licensing or pricing. Stay tuned as we get closer to GA. Having said that, we're pushing hard for a free usage tier and the product team is…

  23. comment
    Comment #35363237

    We encourage folks to draw their own conclusions, but we have done comparisons and ours is more efficient and produces faster results. I only say test yourself because I can't give…

  24. comment
    Comment #35362680

    Not for Omni no. End-users are responsible for any HA/DR/Replication needs. Cloud AlloyDB has all of it built in, but since it was so tightly tied to the Cloud infrastructure it wa…

  25. comment
    Comment #35362657

    100% I'm a huge PG fan as well. This should absolutely be "PG + performance and QoL improvements". Where it's not, we want to hear about it.