malisper

It seems like the title is incorrect:

> GPT-4 identifies SVB’s biggest risk & gives good advice using 2021 balance sheet

From the article GPT-4 gave the likelihood of a bank run as a 1 out of 5. Yes, SVB, made some bad bets, but even with those bad bets they could have continued operating just fine. The thing that actually killed SVB was the $42 billion being withdrawn in a single day out of the $190B in total deposits.

The bad bets were the catalyst that triggered the bank run, but they were not the root cause. The root cause was SVB caters to a specific market segment, venture backed startups, that exhibit herd like behavior. All it takes is a few VCs telling their portfolio companies to move their money out of SVB and suddenly 22% of all deposits are withdrawn. I suspect few banks could survive a similar bank run. None of this is mentioned by GPT-4.

> Does the guidance only apply to user-authenticated web pages?

It depends on if there's health related information on the page. The HHS includes examples of unauthenticated pages where the guidance applies such as pages about a specific health condition or find a doctor pages[0].

[0] https://www.hhs.gov/hipaa/for-professionals/privacy/guidance...

It's not just start ups here. Lots of hospitals and hospital groups have trackers like Google Analytics installed on their website. From the HHS[0] in many cases this is considered sharing health information with Google:

> For example, tracking technologies could collect an individual’s email address and/or IP address when the individual visits a regulated entity’s webpage to search for available appointments with a health care provider. In this example, the regulated entity is disclosing PHI to the tracking technology vendor, and thus the HIPAA Rules apply.

> Were they sending health data

The recent guidance from the HHS[0] indicates in many cases installing Google Analytics or the Facebook SDK would be considered sending health data to Google or Facebook and therefore be considered a HIPAA violation. From the HHS[0]:

> Tracking technologies on a regulated entity’s user-authenticated webpages generally have access to PHI. Such PHI may include, for example, an individual’s IP address, medical record number, home or email addresses, dates of appointments, or other identifying information that the individual may provide when interacting with the webpage.

[0] https://www.hhs.gov/hipaa/for-professionals/privacy/guidance...

I am the founder of a VC backed company

If you don't meet the income requirements for being an accredited investor, the easiest way want to become an accredited investor is to become a licensed investment advisor. Someone wrote an article about their experience becoming licensed[0]

In terms of investment amount, most seed stage companies are willing to take checks as small as $10k, sometimes even lower. If you want to invest in companies that are series A or later, it's unlikely you will be able to participate

[0] https://www.natecation.com/accredited-investor-investing-sta...

Reading through the article, it seems the actual claim is much, much weaker than the title:

> However, all intervention categories and domains apart from “finance” show evidence for heterogeneity, which implies that some nudges might be effective, even when there is evidence against the mean effect

So the article is saying when you look at studies of all "nudges" as whole, adjust for publication bias[0], there isn't evidence for nudges as a whole. Of course individual nudges could still have a positive impact.

Maybe I'm misinterpreting what it's saying, but as an analogy, that would be like doing a study of all "diets", determining that when you combine data for all studies on diets there isn't a positive effect, then writing an article with the claim "no evidence for diets". There's no way you could reasonably make the claim that no diets work.

[0] If you look at the studies on "nudges", studies with smaller sample sizes detected a larger positive effect size. This is because smaller studies that get a positive effect are more likely to be published than smaller studies with a negative effect. The article uses this to analyze just how strong the publication bias is and adjust for it.

> the number of cold emails and calls we get from car part distributors is amusing

Heck, my company is called Freshpaint. The number of people that visit our site, freshpaint.io, see all the copy about data infrastructure, and still contact us looking for a quote to paint their house is hilarious.

> It's not specified in the article?

From the article:

> The function should have expected O(1) performance.

> Do that for rate limiting and it'll be super easy to DoS you

How so? The rate limiter has the same performance as, for example, a hash table. Operations are usually O(1), but are periodically O(n). It's not like every service that uses a hash-table is DoS-able.

> hence the proposed solution has a worst case complexity of O(N)?

Worst case yes, but the question is concerned with the average case.

> "Produce a dictionary of the number of times each letter occurs in each word." is heading the wrong direction. You want an encoding that does not care about the number of times each letter occurs in each word.

How so? "aab" is an anagram of "baa", but they are not anagrams of "ab".

> The solution described in the article is likely to be extremely wasteful in both time and memory, by allocating a queue entry for each call, and then O(n) scanning and dropping stale entries on each successive call.

Even if n elements are scanned in the the worst case, the expected time it takes to perform such a scan is O(1). This is because we perform a scan on each insertion and O(n) elements are deleted in a scan of length n. That means the number of elements scanned is proportional to the number of elements inserted.

> Tabulating call count by division(s) of time would be less obviously problematic.

Tabulating call count by division(s) of time doesn't quite work. If a 9 calls are made at the last second of one division of time and 9 more calls are made in the first second of the next division of time, you will hit 18 calls in a two second interval which is over the limit of 10 calls for any one minute interval.

> Rate limiter: I would probably use a hash table of this structure -- called[yyyy-mm-dd][hh-mm] and then increment the hashtable for that minute, for example, called[2022-01-02][22-01]++ and drop any entries for the last day at the end of the day.

As Bradley said this implementation can be called more than 10 times within a 1 minute window. If it's called 9 times at the last second of one minute and 9 times at the start of the next minute, it will be called 18 times within a two second interval.

The "algorithm" I wrote in this post is a formalized version of some problem solving techniques I picked up from the classic book "How to Solve It"[0]. In particular "working backwards". You start from the goal you want and see what you know that is applicable to getting you to goal.

[0] https://en.wikipedia.org/wiki/How_to_Solve_It

There's a specific reason I didn't mention priority queues in the post. In most cases, anything you can do with a heap you can do with a binary tree instead! A binary tree has O(log(n)) insert and deletion which is the same as a traditional heap. The only advantage a traditional heap has is you can construct a heap in O(n) time whereas a binary tree takes O(nlog(n)) time.

Of course there are even more niche data structures like a Fibonacci heap which have O(1) insertion, but you will have to get extremely unlucky to get asked about a Fibonacci heap in an interview.

The post touches upon it, but I didn't really understand the point. Why doesn't synchronous replication in Postgres work for this use case? With synchronous replication you have a primary and secondary. Your queries go to the primary and the secondary is guaranteed to be at least as up to date as the primary. That way if the primary goes down, you can query the secondary instead and not lose any data.

(I used to work at Heap.)

I think the post is spot on and it shows the Satchel team put did a ton of research into the post. There are two comments I would make on top of the post. First, know if the advice applies to you. If you are pre-product market fit it's probably too early to think about event based analytics. If you have a small number of users and are able to talk with all of them, you will get much more meaningful data getting to know them than if you were to set up product analytics. You probably don't have enough users to get meaningful data from product analytics anyways.

Second, while the autotrack functionality at Heap is fantastic, what I saw was that a significant portion of Heap's customers were not able to use it. This primarily happened because in addition to using Heap's autotrack to collect data, a lot of Heap's customers were also using Segment to collect and route the data between different tools. This created two different sources of truth for the data and Segment usually wound up winning. For that reason, I left Heap ~18 months ago to start Freshpaint (freshpaint.io). Freshpaint is an autotrack based alternative to Segment, allowing you to autotrack data and feed that same dataset into all your different tools. That way you get all the advantages of autotrack without needing to maintain two sources of truth.

That's a different argument that what most people in the thread are making and in my opinion, a reasonable one.

ITT: people claiming DoorDash has no path to profitability - the numbers in the S-1 tell a different story. On page 112, there's a chart of how much profit they make per order based on how long the user has been on the platform. In the first year, the value is negative because DoorDash spends money on sales and marketing to acquire the customer. By the third year, DoorDash is making a consistent profit of 8% on each order placed.

When you look at the numbers in aggregate, it appears they are massively unprofitable. When you look at the numbers by cohort, it's clear they are investing money in sales and marketing and based on their metrics, they will generate a significant return on their investment over the next few years. Over time, as a larger and larger percentage of their users become recurring users, their profit on each order will approach 8%.

IIRC, EXPLAIN VERBOSE will show you the columns being selected by each step of the plan. The inlining showed up there.

I've mentioned this story here before, but one of the most surprising performance gains I saw was by eliminating TOAST look ups. If I recall correctly, each time you use the `->>` operator on a TOASTed JSONb column, the column will be deTOASTed. That means if you write a query like:

  SELECT x ->> 'field1', x ->> 'field2', x ->> 'field3'
  FROM table

and x is TOASTed, Postgres will deTOAST x three different times. This multiplies the amount of data that needs to be processed and dramatically slows things down.

My first attempt to fix this was to read the field in one query and use a subselect to pull out the individual fields. This attempt was thwarted by the Postgres optimizer which inlined the subquery and still resulted in deTOASTing the field multiple times.

After a discussion with the Postgres IRC, RhodiumToad pointed out that if I add OFFSET 0 to the end of the subquery, that will prevent Postgres from inlining it. After retrying that, I saw an order of magnitude improvement due to eliminating the redundant work.

For a post detailing the modern data infrastructure I'm surprised they intentionally leave out SaaS analytics tools. I find this especially surprising given a16z has invested >$65M into Mixpanel.

Based on my experience working at an analytics company and running one myself, what this post misses out is that an increasing number of people working with data today are not engineers. These people can range from product managers who are trying to figure out what features the company should focus on building, marketers to figure out how to drive more traffic to their website, or even the CEO trying to understand how their business as a whole is doing.

For that reason, you'll still see many companies pay for full stack analytics tools (Mixpanel, Amplitude, Heap) in addition to building out their own data stack internally. It's becoming more and more important that the data is accessible to everyone at your company including the non-technical users. If you try to get everyone to use your own in-house built system, that's not going to happen.

> Absolutely false. This is simply not how copyright works!

How so? Here's what section 5 of the AGPL says[0]:

> You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:

> c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.

As for patents which is covered in section 11:

> If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to be so available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of this License, to extend the patent license to downstream recipients.

[0] https://www.gnu.org/licenses/agpl-3.0.en.html

> Disgusting amount of control over people's lives. Y'all need a union.

FWIW this is more Google being risk adverse than Google being evil. If a Google employee in their free time contributes to an AGPL project, that employee needs to open source all IP related to their contribution to the project. Depending on the specifics and how the AGPL is interpreted in court, Google could be forced to open source their internal IP.

FWIW, I believe all large companies take a similar stance on the AGPL.

> But this only can happen if replace X with Y and add Z are in the same transaction. If you rollback the transaction, then you start by removing Z, then replacing Y with X. What I'm missing here?

Z can be in a different transaction than X and Y. If two transactions run concurrently, one that replaces X with Y and a second one that inserts Z, the above scenario can happen.

> Does it do this in the reverse order?

I would guess so, but I haven't looked up the implementation so I'm not sure. There's a ton of race conditions that can come up depending on the exact order you write things so I'm sure the actual implementation is pretty messy.

In Postgres 12, the pluggable storage API was introduced. That allows use of multiple different storage engines with Zheap being one of the new storage engines.

IIRC, one of the big reasons for implementing pluggable storage was for Zheap.

FWIW, the existing implementation has worked really well for most use cases.

For those unaware, Zheap is a new storage engine for Postgres that handles updates and deletes in a different way. Currently, when you update a row in Postgres, Postgres creates a new copy of the row and marks the old one as deleted. This is done for several reasons, specifically it makes handling concurrency easier and it makes rolling back transactions easier.

The issue with this approach is over time this leads to lots of "dead rows" - deleted rows that are taking up space in your DB. Postgres has a background job called the "vacuum" which effectively garbage collects all deleted rows. Depending on your settings, the vacuum can be a pretty expensive job and even with the vacuum, you can still wind up using a lot more space than you actually need.

Zheap addresses these problems by using a different approach. When performing an update, instead of marking the old row as deleted and inserting a new one, Postgres will replace the old row with the new one and write a copy of the old row to a separate file. This means the main table file doesn't need to be larger than necessary to keep track of the dead rows.

Zheap does lead to lots of tricky scenarios. If for any reason you need to access the old copy of the row, you have to fetch it from the separate file. If the transaction that performed that update is rolled back, you need to replace the new version of the row with the old version of the row. This sounds straightforward, but gets really tricky really fast. For example, what happens if I have row X that takes up 1kb. I replace it with row Y that takes up 500b. I then write row Z after row Y that takes up 500b. If you want to rollback the original transaction, row X will no longer fit in its original spot because row Z is now taking up part of the space it used to occupy.

Q: Since users of Plausible are sending you their visitors IP addresses, doesn't that mean GDPR applies? GDPR mentions "disclosure by transmission" as an example of processing[0].

Since that's the case, doesn't that mean you need a legal basis for processing the data[1], you need a way to allow users to opt out of collection of their data[2], and your clients need to sign data protection agreements[3] with Plausible?

I tried looking for Plausible's point of view on this and how they address the above, but I couldn't find anything.

[0] https://gdpr-info.eu/art-4-gdpr/

[1] https://gdpr-info.eu/art-6-gdpr/

[2] https://gdpr-info.eu/art-21-gdpr/

[3] https://gdpr-info.eu/art-28-gdpr/

GDPR article 12[0] explicitly permits this:

> Without prejudice to Article 11, where the controller has reasonable doubts concerning the identity of the natural person making the request referred to in Articles 15 to 21, the controller may request the provision of additional information necessary to confirm the identity of the data subject.

Article 17 deals with requesting the deletion of data and article 21 deals with objecting to the processing of your data.

In fact, not verifying the identity of individuals could be legally dangerous because you are in effect allowing an individual to tamper with another individual's data.

[0] https://gdpr-info.eu/art-12-gdpr/

(I'm the author of the post.)

I've worked with a large Postgres cluster before (~1PB of data) and have been experimenting with Snowflake recently. I would say there's two clear technical advantages of Snowflake over Redshift. First is there's no maintenance when using Snowflake. You just signup for a Snowflake account, upload a CSV, and you can start querying the data. This is in contrast to Redshift where you have to manually provision a cluster, resize it as you add more data, etc.

The second is their pricing. Storing data in Snowflake costs the same as it would cost to store in S3. The tradeoff is you also have to pay based on how long your queries take. Depending on your workload this can result in a massive cost savings. If you access only small amounts of your data infrequently, it's like you're storing the data in S3 and you only have to pay a bit more when accessing the data. This is in contrast to Redshift where you have to pay for the full cost of the cluster regardless of whether you are actually querying the data or not.

Snowflake also has a ton of quality of life improvements compared to Redshift. One really nice thing is you can change the amount of compute used for any individual query. For example, if you have one specific slow query, you can allocate 4x the compute for that one query, pay 4x as much while the query is running, and get the query to run 4x faster (ultimately costing you the same amount as if you used 1x the compute).

One neat thing is there's ultimately only one "Snowflake instance" in each region. Everyone's tables are in the same instance, but you can only access the tables you have permission to access. This allows you to easily share data between different Snowflake accounts. You can store the data in one account and query it from another.

So the core value proposition is really strong and it also has a bunch of extra features that are all pretty useful at the end of the day.

This post focused on Snowflake solely from a business point of view. I'm considering writing another one that focuses on it from a technical point of view.