I have a project Archive page as below.

As you can see, I bring all the projects and perform filter, sort and pagination operations.

---
interface Props {
  page?: string;
}

const { page } = Astro.props;

// Projects
const projects = (
  await getCollection("projects", ({ data }) => {
    return data.get.language === language && data.get.status === "publish";
  })
).sort((a, b) => {
  const sortOrders = b.data.get.sortOrder - a.data.get.sortOrder;
  return sortOrders !== 0
    ? sortOrders
    : Date.parse(b.data.get.publishDate) - Date.parse(a.data.get.publishDate);
});

// Get featured projects
const featuredProjects = projects.filter(
  (data) => data.data.get.featured === true
);

// Find featured project
const featuredProject = featuredProjects.length ? featuredProjects[0] : null;

// Normal projects
const normalProjects = featuredProject
  ? projects.filter((data) => data != featuredProject)
  : projects;

// Total pages
const totalPages: number = Math.ceil(
  normalProjects.length / options.postsPerPage
);

// Current page
const currentPage = +page! || 1;

// Current page's projects
const currentProjects = normalProjects.slice(
  (currentPage - 1) * options.postsPerPage,
  currentPage * options.postsPerPage
);
---
<div></div>

What came to my mind was the possibility of slowdowns and even crashes in the long run as the number of projects increases due to excessive memory usage by these processes.

Yes, there won't be that many projects, but I will use this structure in the future for archives like "Blog" etc. And yes, the number of blogs can be quite high.

That's why I want to take precautions at the source before the problem even starts, and I ask, will this structure cause major problems in the future when there is a lot of archive content?

Your answer is probably yes (otherwise you would make me very happy), so:

The biggest problem here (while probably displaying 10-20 of them on a single page) is calling all of them with getCollection.

1. In this case, if I put the pagination in getCollection and query the content as much as the first perPage + 1 each time, and if that much content is returned, I should know that the next page will also have at least 1 item.
2. Does this approach eliminate any performance issues that may arise?
3. I'm afraid that with this approach I won't know the value of totalPages, so I'll have to use <next-prev> Pagination instead of Numeric Pagination, which is very bad. (Is there a preformed way to get around this and get the total number of pages?)
4. With all this, without directing you: If anyone has another solution or suggestion that is completely unique to you, I would be happy to read them.

All things aside: I don't know if there is a way to "get" content between 1 and 10, 11 and 20, 21 and 30 ... when querying the getCollection function (see here) :D

Before I fet: The project is SSR (running server-side).